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

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

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

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

Уровень техники

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

Сущность изобретения

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

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

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

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

Краткое описание чертежей

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

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

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

Фиг. 3 изображает схематичное представление другого варианта осуществления режима VPG.

Фиг. 4 изображает схематичное представление одного варианта осуществления реализации VPG.

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

Фиг. 6 изображает схематичное представление одного варианта осуществления виртуализации плоскости администрирования VPG.

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

Фиг. 8 изображает схематичное представление одного варианта осуществления виртуализации плоскости управления VPG.

Фиг. 9 изображает схематичное представление другого варианта осуществления виртуализации плоскости управления VPG.

Фиг. 10 изображает схематичное представление другого варианта осуществления виртуализации плоскости управления VPG.

Фиг. 11 изображает схематичное представление другого варианта осуществления виртуализации плоскости управления VPG.

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

Фиг. 13 изображает схематичное представление одного варианта осуществления виртуализации плоскости транспортировки VPG.

Фиг. 14 изображает блок-схему одного варианта осуществления способа плоскости управления VPG.

Фиг. 15 изображает схематичное представление одного варианта осуществления передающего/принимающего блока.

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

Подробное описание

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

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

Здесь раскрываются системы и способы для обслуживания различных пользователей или групп пользователей, которые могут иметь различные предпочтения и требования. Группа пользователей (обычно соединенная с общим объектом, может группироваться ситуативным (ad hoc технология) образом), которая может иметь общий набор предпочтений в плане требований к тому, как CON SP должен администрировать ее содержимое, здесь называется VPG (мы используем термин "VPG" как более общий термин вместо "VPN", поскольку традиционно "VPN" использовалось для указания экземпляра предприятия в совместно используемой инфраструктуре. В нашем контексте VPG может быть VPN или любой группой пользователей/объектов, пытающихся достичь общей цели). Группа может быть виртуальной в том смысле, что участники группы могут быть географически рассредоточены, и логически накладываться на инфраструктуру CON. Группа также может быть закрытой в том смысле, что CON может обеспечивать возможность группе сохранять свойства VPG (в плане распространяемого содержимого) аналогично случаю, когда администрирование распространения содержимого выполняется самими VPG. VPG может быть любым набором пользователей, которые объединены общими свойствами в аспектах, относящихся к членству, ресурсам (например, информационному ресурсу и ресурсу сетевого объекта), производительности, защите, надежности или комбинациям перечисленного. К примеру, VPG может быть предприятием, создателем/распространителем содержимого (например, Netflix, Hulu и т. д.) или сетевым продавцом (Amazon, Walmart и т. д.) с объектами, которые могут быть географически распределены, и чьи SLA-требования могут быть строгими в отношении производительности, защиты и/или надежности. Альтернативно VPG может являться некой формой социальной сети (например, Facebook, Youtube и т. д.), которая может связывать пользователей по их общим интересам.

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

Фиг. 1 изображает вариант осуществления архитектуры 100 CON, где содержимое объектов уникальным образом идентифицируется по ID и доставляется клиентам на основе запроса для него. Архитектура 100 CON может содержать множество клиентских узлов/пунктов 112, которые могут публиковать (выдавать) и/или подписывать или запрашивать (извлекать) содержимое в CON 110. Клиентские узлы/пункты 112 могут соответствовать пользователям и/или пользовательским приложениям. Пользователями могут быть издатели, подписчики, предприятия (например, сферы здравоохранения, финансовые, страховые, киностудии и т. д.), социальные сети, государственные органы, сети служб быстрого реагирования, сети приборов обнаружения, сети передачи данных, сети мобильных объектов (M2M), другие типы пользователей содержимого или комбинации перечисленного.

Клиентскими узлами/пунктами 112 могут быть узлы, устройства или компоненты, сконфигурированные для доставки содержимого к и приема запросов на содержимое от пользователей или пользовательских приложений. К примеру, клиентские узлы могут быть стационарными или мобильными устройствами, ориентированными на пользователя, такими как настольные компьютеры, ноутбуки, "электронные помощники" (PDA) или сотовые телефоны. Альтернативно клиентскими узлами могут устройства подключения на территории клиента, такие как модемы или декодеры каналов кабельного телевидения. Клиентские узлы также могут содержать клиентское оборудование (не показано), которое может конфигурироваться для приема содержимого от CON 110, например, через сети доступа и распределения содержимого для множества клиентов 112. К примеру, клиентские узлы могут содержать терминалы оптических сетей (ONU) и/или приемопередающие блоки сверхскоростной цифровой абонентской линии (VDSL) в городских поселениях (VTU-R). Сетями доступа могут быть любые сети, которые обеспечивают доступ к содержимому в CON 110, такие как виртуальные частные сети (VPN).

CON 110 может обеспечивать множество служб клиентским узлам/пунктам 112, включая публикацию/подписку на или запрашивание содержимого, кэширование/хранение содержимого, поддержку мобильности клиента, защиту и/или другие ориентированные на содержимое службы. Также CON 110 может называться здесь информационно-направленной сетью (ICN). CON 110 может содержать множество сетевых узлов 130, которые могут быть соединены друг с другом по сетевым линиям связи, например, фиксированным соединениям. Сетевыми узлами 130 могут быть любые узлы, устройства или компоненты, которые поддерживают транспортировку трафика, например, кадров и/или пакетов, через CON 110. Сетевые узлы 130 могут передавать трафик к или принимать трафик от других узлов в CON 110. Сетевые узлы 130 могут содержать множество серверов содержимого, которые хранят или кэшируют содержимое, которое может обеспечиваться пользователям или подписчикам, например, по требованию. К примеру, сетевыми узлами 130 могут быть маршрутизаторы, переключатели или мосты, такие как магистральные центральные мосты (BCB), центральные мосты провайдера (PCB) или маршрутизаторы коммутации отметок (LSR).

Дополнительно сетевые узлы 130 могут содержать маршрутизаторы содержимого, которые перенаправляют содержимое на основе префиксов имен содержимого. Маршрутизаторы содержимого могут конфигурироваться для маршрутизации, кэширования и/или хранения содержимого. Некоторые из маршрутизаторов содержимого, например граничные узлы, могут соединяться с клиентскими узлами/пунктами 112, например, через множество сетей доступа, проводных линий связи или беспроводных линий связи. Маршрутизаторами содержимого могут быть граничные узлы и, возможно, центральные узлы в CON 110, которые перенаправляют трафик содержимого к клиентским узлам/пунктам 112 на основе клиентского запроса или требования. Маршрутизаторы содержимого также могут принимать запросы на содержимое от клиентских узлов/пунктов 112. К примеру, маршрутизаторы содержимого являются улучшенными версиями традиционных маршрутизаторов или мостов, таких как базовые граничные мосты (BEB), граничные мосты провайдера (PEB) или граничные маршрутизаторы меток (LER), которые перенаправляют содержимое на основе префиксов имен содержимого, с точки зрения транспортировки, роли этих узлов могут быть одинаковыми (даже для обратной совместимости), но важнее то, что им обеспечена возможность распределения содержимого посредством таких характеристик, как динамическое/постоянное кэширование и помощь уровня приложений. Эти маршрутизаторы содержимого могут также быть полнофункциональными CCN-маршрутизаторами или маршрутизаторами содержимого на основе других предложений, и в таком случае задача распространения содержимого связана с транспортировочным уровнем. Сеть может быть комбинацией этих базовых маршрутизаторов содержимого, традиционных маршрутизаторов/переключателей или комбинацией перечисленного с учетом случая внедрения этих технологий будущего.

В архитектуре 100 CON CON 110 может иметь инфраструктуру 120 плоскости CON, которая обслуживает обеспечение различных служб клиентским узлам/пунктам 112. Инфраструктура 120 плоскости CON содержит множество плоскостей функционирования, которые поддерживают различные службы для клиентских узлов/пунктов 112. К примеру, инфраструктура 120 плоскости CON содержит плоскость администрирования, плоскость хранения и вычисления, плоскость управления, плоскость содержимого (также называемая плоскостью данных содержимого), плоскость транспортировки. Различные плоскости могут обрабатывать различные аспекты операций CON и ресурсов, относящихся к содержимому, службам и клиентским узлам/пунктам 112, такие как администрирование, хранение, управление и транспортировка. Как правило, каждая из плоскостей может обслуживать клиентские узлы/пункты 112 и их соответствующее содержимое и поддерживать службы для различных клиентских узлов/пунктов 112, например, в плане производительности, защиты и надежности по существу аналогичным или ровным образом. Однако клиентские узлы/пункты 112 могут принадлежать к различным группам, например, различным VPG, которые могут иметь различные требования (например, требования качества обслуживания (QoS)), SLA и/или другие политики. Как правило, линия поведения ровной плоскости у плоскостей в инфраструктуре 120 плоскости CON не учитывает различные требования VPG, что может вызывать уменьшенную производительность сети и избыточный расход сетевых ресурсов. К примеру, распространение содержимого для различных VPG, которые имеют различные SLA, аналогичным образом может помешать эффективному балансированию нагрузки в CON 110.

В одном варианте осуществления CON 110 может являться ICN, где кэшированное содержимое может иметь одного или нескольких владельцев, которые могут ассоциироваться с одним или несколькими клиентскими узлами/пунктами 112. Владельцы могут полагаться на провайдеров служб (SP) ICN для доставки содержимого к авторизованным пользователям (например, также ассоциированным с клиентскими узлами/пунктами 112). Таким образом, ICN может конфигурироваться для обеспечения различного содержимого различных владельцев соответствующим пользователям на основе различных требований, ассоциированных с различными владельцами. Требования могут относиться к производительности (например, хранение, вычисление и/или полоса частот), доступности, надежности, защите или комбинациям перечисленного. В частности, пользователи содержимого от различных владельцев и владельцы могут быть разделены на множество VPG. Таким образом, различные плоскости в инфраструктуре 120 плоскостей CON могут быть виртуализированы, например, сконфигурированы или предоставлены для обработки и обслуживания множества экземпляров VPG, которые соответствуют VPG, как описано ниже.

Фиг. 2 изображает вариант осуществления инфраструктуры 200 плоскости CON, которая может поддерживать множество VPG, которые имеют различные требования, SLA и/или другие политики, эффективным образом. В частности, инфраструктура 200 плоскости CON может поддерживать множество экземпляров VPG на множестве плоскостей функционирования, например, в плане администрирования, производительности, защиты и надежности. Экземпляры VPG могут содержать первый экземпляр VPG (VPG-A) и второй экземпляр VPG (VPG-B), которые могут иметь соответствующие приложения, персональные настройки и политики. Инфраструктура 200 плоскости CON может обеспечивать возможность межгруппового взаимодействия VPG между экземплярами VPG. Дополнительно инфраструктура 200 плоскости CON может поддерживать открытый доступ для клиентов или пользователей, которые могут не принадлежать к экземплярам VPG, например, согласно политикам по умолчанию.

Плоскости функционирования в инфраструктуре 200 плоскости CON могут содержать плоскость 210 содержимого VPG, плоскость 220 управления VPG, плоскость 230 хранения и вычисления VPG (также называемую плоскостью администрирования ресурсами), плоскость 240 транспортировки VPG и плоскость 250 администрирования VPG для поддержки различных экземпляров VPG и открытого доступа на основе их соответствующих политик. Плоскость 210 содержимого VPG может конфигурироваться для поддержки различных защитных SLA экземпляров VPG и открытого доступа и обрабатывать обеспечение исполнения политик. Плоскость 220 управления VPG может конфигурироваться для того, чтобы обрабатывать маршрутизацию и разрешение для различных экземпляров VPG и открытого доступа. Плоскость 230 хранения и вычисления VPG может конфигурироваться для того, чтобы обрабатывать хранение и вычисление для различных экземпляров VPG и открытого доступа. Плоскость 240 транспортировки VPG может конфигурироваться для того, чтобы обрабатывать перенаправление данных и осуществлять администрирование ресурсами для различных экземпляров VPG и открытого доступа. Плоскость администрирования 250 VPG может обеспечивать возможность взаимодействия между различными VPG-пользователями 260 и различными плоскостями инфраструктуры 200 плоскости CON, например, посредством служебных интерфейсов 252 программирования приложений (API) VPG. Служебные API VPG могут конфигурироваться для поддержки служебных элементарных действий ICN и/или персональных настроек приложений для различных экземпляров VPG. Служебные API могут содержать различную информацию, включая тип, VPG, пользователя и/или служебный идентификатор (VPG-ID), информацию защиты, содержимое, информацию действия и/или другую информацию.

Фиг. 3 изображает вариант осуществления режима 300 VPG, который может быть установлен на маршрутизаторе содержимого для поддержания экземпляра VPG, например, на основе инфраструктуры 200 плоскости CON. Маршрутизатор содержимого может конфигурироваться аналогично маршрутизаторам содержимого, описанным выше, и может осуществлять маршрутизацию объектов содержимого, которые относятся к экземпляру VPG, с использованием режима 300 VPG. В случае множества VPG маршрутизатор содержимого может установить режим 300 VPG для каждого экземпляра VPG. Режим 300 VPG может осуществлять маршрутизацию содержимого, ассоциированного с VPG, на основе множества соответствующих VPG-политик 330 и с использованием постоянного кэша или буфера 340, специализированного для экземпляра VPG. Постоянный кэш или буфер 340 может являться частью физического буфера или компонентом хранения маршрутизатора содержимого.

Режим 300 VPG может осуществляться во множестве плоскостей функционирования, включая плоскость администрирования, плоскость содержимого, плоскость управления и плоскость транспортировки. К примеру, режим 300 VPG может осуществлять в плоскости 310 содержимого VPG множество функций для обеспечения маршрутизации содержимого. Функции плоскости содержимого могут осуществляться с использованием логики 314 обработки приложения VPG, которая может обрабатывать содержимое, и средства перенаправления решения 316 VPG, которое может принимать решение о надлежащей маршрутизации на основе информации содержимого. Режим 300 VPG также может осуществлять в управляющей плоскости 320 VPG множество функций для поддержки маршрутизации содержимого. Функции плоскости управления могут осуществляться с использованием протокола 322 маршрутизации содержимого VPG, API 324 службы/администрирования VPG, протокола 326 разрешения VPG и/или сигнального протокола 312 VPG. Дополнительно режим 300 VPG может осуществлять в плоскости транспортировки VPG множество функций для перенаправления содержимого в CON. Функции плоскости транспортировки могут осуществляться с использованием виртуализированного перенаправления 318, например, установленного для экземпляра VPG, на основе соответствующих виртуализированных транспортировочных ресурсов 319 (например, QOS-ресурсов) для экземпляра VPG.

Множество режимов 300 VPG на одном или нескольких маршрутизаторах содержимого может обеспечивать возможность маршрутизатору содержимого и CON обеспечивать закрытую обработку для данных или содержимого, например, для множества VPG (например, владельцев содержимого), в открытой или совместно используемой инфраструктуре CON. Это также может обеспечивать возможность для VPG согласовывать различные SLA с CON или SP ICN для удовлетворения требований VPG. Таким образом, SP ICN может использовать свои ресурсы более эффективно к примеру путем мультиплексирования ресурсов между множеством VPG. SP ICN также может обслуживать множество пользователей с различными требованиями путем приоритезации реакций на сбой, таких как восстановление служб в случае сбоев, на основе приоритета клиента.

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

CON также может использовать парадигму защиты на уровне групп для осуществления политик защиты на уровне VPG для множества или всех участников CON. На уровне защиты участника VPG CON может быть задействована или не задействована. Если CON задействована, то CON может обеспечивать исполнение более тонких характеристик управления политики защиты по сравнению с уровнем VPG, например, как требует VPG для своих участников. CON также может обеспечивать возможность участникам определять их собственную политику защиты в контексте VPG. Множество индивидуально-пользовательских функций уровня защиты может использоваться и обрабатываться особым образом самим клиентом VPG, и в таком случае CON может не задействоваться в каких-либо задачах, относящихся к защите. Альтернативно CON может перенимать на себя ответственность доставки всех гарантий, относящихся к защите, участникам VPG. См., например, патентную заявку США № 13/226605, поданную 7 сентября 2011 г. и озаглавленную "Method and Apparatus to Create and Manage a Differentiated Security Framework for Content Oriented Networks", которая включена сюда посредством ссылки. Идеи, представленные в этой патентной заявке, могут быть типом службы, которую CON-провайдер может обеспечивать в качестве выбора для VPG. В качестве другой альтернативы может использоваться гибридная модель, в которой индивидуально-пользовательские функции уровня защиты могут разделяться между VPG и CON. Гибридная модель может являться адекватным компромиссом с точки зрения как сложности, так и бизнес-модели.

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

Доступность требований может содержать гарантию, что участник VPG имеет возможность осуществить доступ к данным в CON из сторонней сети и/или из какого-либо места, независимо от того, является ли участник мобильным или имеет фиксированное или редко изменяющееся местоположение. Требования готовности могут содержать гарантию в отношении степени готовности элемента содержимого, публикуемого VPG для сети. Готовность может быть обеспечена путем дублирования содержимого во множество мест. Дублирование может требоваться для того, чтобы сделать процесс распространения содержимого VPG более эффективным, поскольку большее дублирование данных может дать в результате улучшенное QoS для участников VPG. Дополнительно дублирование может требоваться для учета сбоев, таких как сбой маршрутизатора содержимого или линии связи, которые могут вызывать отсоединение сетевых объектов от сети. В этом случае дублирование может обеспечивать возможность доступности копии содержимого с повышенной вероятностью. Требования надежности могут содержать гарантию уровня служб в отношении политик времени бездействия, отказоустойчивости, горячих резервов и/или защитного переключения, к примеру с учетом сбоя ресурсов хранения или сети и/или уязвимости мест, где инфраструктура CON содержит VPG. Вышеупомянутые факторы готовности могут зависеть от надежности инфраструктуры.

QoS-требования, например, с точки зрения плоскости содержимого, можно перевести в параметры, которые имеют значение для участников VPG. QoS-требования также могут изменяться в зависимости от типа применений. Отображение качества опыта (QoE) пользователя в QoS-требования уровня сети четко зафиксировано в нескольких смежных стандартах. К примеру, в случае служб реального времени задержка между пунктами и неустойчивость сигнала могут быть параметрами, заслуживающими большего внимания, там где службы потока и просмотра чувствительны к времени отклика и потерям пакетов. Эти параметры производительности могут быть получены путем разбивания QoS-ресурсов между пунктами на функции плоскости управления и данных в плоскости содержимого. Эта форма гранулированного планирования ресурсов может быть первым этапом для обеспечения исполнения и проектирования QoS-требований, которые могут быть удовлетворены на практике. Дополнительно несколько приложений могут использовать уровень содержимого на стороне пользователей для публикации или выведения их соответствующего содержимого. Взаимодействия плоскости содержимого могут происходить на уровне уровня приложений в модели взаимодействия открытых систем (OSI). Обеспечение возможности VPG иметь экземпляр приложения в CON может обеспечивать возможность VPG распространять содержимое эффективно своим участникам, а также улучшать QoE участников соответственным образом, например, для обеспечения требований персональной настройки приложения.

Фиг. 4 изображает вариант осуществления реализации 400 VPG. Реализация 400 VPG может содержать идентификацию ресурсов распределенного хранения, вычисления и/или полосы частот, распределенных по сети. Некоторая форма возможности подключения может использоваться для идентификации и логического соединения этих различных ресурсов. Реализация 400 VPG может осуществляться в архитектуре CON, аналогичной архитектуре 100 CON. Архитектура CON может содержать CON 410, которая содержит множество соединенных друг с другом маршрутизаторов 412 содержимого. CON 410 и маршрутизаторы 412 содержимого могут конфигурироваться аналогично соответствующим вышеописанным компонентам. Некоторые из маршрутизаторов 412 содержимого, например граничные узлы, могут соединяться с множеством клиентов 420, например, через сети доступа, которые могут ассоциироваться с одной или несколькими VPG. Некоторые из клиентских узлов/пунктов 420 могут соответствовать одной VPG (VPG-A) и могут содержать множество пользователей, распределенных по множеству географических мест или пунктов, например Пользовательский-Пункт-1, Пользовательский-Пункт-2 и Пользовательский-Пункт-3. Соответственно, некоторые из маршрутизаторов 412 содержимого могут устанавливать соответствующий экземпляр VPG для обработки маршрутизации содержимого для VPG-A, например, на основе режима 300 VPG и инфраструктуры 200 плоскости CON.

Экземпляр VPG в маршрутизаторе 412 содержимого может обеспечивать исполнение SLA-требований VPG, описанных в плоскостях управления, администрирования и транспортировки, относящихся к распространению содержимого. Это может требовать конфигурацию, резервирование ресурсов хранения/транспортировки, обеспечение исполнения политик и реализацию протоколов управления/данных для каждой VPG. Реализация 400 экземпляра VPG может относиться к тому, где одна или несколько VPG могут быть реализованы или быть установлены в CON 410 с использованием группы маршрутизаторов 412 содержимого для каждой VPG. Реализация 400 VPG также может относиться к количеству ресурсов, которое должно быть назначено для удовлетворения SLA-требований, согласованных между VPG и CON. Эти аспекты могут рассматриваться с учетом множества факторов, включая: 1) географическое распределение VPG-пользователей; 2) пользовательское поведение, из которого пользовательский запрос и получаемое в результате требование трафика может быть спрогнозировано для участников VPG в одном пункте; 3) требования приложений и тип содержимого, запрашиваемого пользователями; и 4) пользовательские ожидания в плане SLA-параметров.

Следуя традиционной модели предоставления VPN, может быть реализована VPG на граничных узлах без какого-либо режима VPG в центре CON или ICN. Однако может быть выгодным воздействовать на центр ICN для улучшения поставки содержимого. На основе схемы реализации 400 VPG как граница, так и центр CON 410 могут использоваться для установления экземпляра VPG. Однако некоторые, но не обязательно все, маршрутизаторы 412 содержимого в CON 410 могут устанавливать режимы VPG. Любой из маршрутизаторов 412 содержимого в CON 410 может иметь возможность кэширования и, следовательно, обслуживания содержимого. Реализация VPG только на граничных узлах может быть проще в осуществлении, например, в плане администрирования, но может не обеспечивать оптимального или эффективного решения для VPG в плане распространения содержимого. Альтернативно размещение экземпляра VPG на всех или каждом маршрутизаторе 412 содержимого может быть избыточным и может существенно увеличить служебное сигнализирование сети. Предпочтительный подход для преодоления ограничений обоих решений может состоять в выборе поднабора маршрутизаторов 412 содержимого, что может являться компромиссом между обоими подходами. Таким образом, поднабор маршрутизаторов 412 содержимого, который может использоваться в CON 410, может содержать как граничные узлы, которые могут быть посредниками для пользовательских запросов, так и центральные узлы, которые могут обеспечивать исполнение SLA-требований VPG.

Реализация 400 VPG может осуществляться для множества VPG на основе множества входных данных, включая ожидаемое требование содержимого, например, географическое распределение, количество пользователей, количество пунктов, пользовательское поведение, профиль трафика, рабочие нагрузки или комбинации перечисленного. Входные данные также могут содержать SLA-требования (например, в плане готовности и дублирования), производительность (например, в плане пропускной способности и QoE/QoS), надежность (например, в плане времени бездействия, сбоев и/или горячих резервов)). Входные данные также могут содержать сетевые аспекты, например, в плане ресурсов хранения, вычисления и полосы частот, и экономические соображения, например, в плане затрат хранения/полосы частот/вычисления и ограничений ресурсов. Реализация 400 VPG может основываться на задаче оптимизации, например, задачах ICN в плане уменьшения использования ресурсов, увеличения QoE пользователей и/или увеличения дохода. Реализация 400 VPG может обеспечивать множество выходных данных, включая поднабор маршрутизаторов 412 содержимого, где VPG должен быть реализован, виртуализированные или предоставленные ресурсы (например, для хранения и вычисления) на каждом выбранном маршрутизаторе 412 содержимого и ресурсы полосы частот, требуемые для обеспечения производительности, готовности и надежности. Выходные данные также могут содержать предварительное определение маршрутизации над ресурсами полосы частот или применение маршрутизации к VPG-требованиям. Защита реализованного VPG может основываться на схеме защиты, описанной в патентной заявке США № 13/226605, поданной 7 сентября 2011 г. СиньУэнь Чжаном (Xinwen Zhang) и др. и озаглавленной "Method and Apparatus to Create and Manage a Differentiated Security Framework for Content Oriented Networks", которая включена в настоящий документ посредством ссылки.

Одним из учитываемых ресурсов при реализации VPG является назначение ресурса хранения пользователю. Это хранилище может содержать место хранения для кэширования объектов содержимого на основе нужд реального времени VPG-участников и постоянное хранилище. На основе схемы распределенного кэширования, которая используется, экземпляры VPG на маршрутизаторах 412 содержимого могут индексироваться в локальном хранилище (локально в маршрутизаторах 412 содержимого) и/или удаленно