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

Abstract

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

Description

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

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

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

В ориентированной на содержимое сети (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 содержимого) и/или удаленном хранилище (в удаленных маршрутизаторах 412 содержимого). Множество схем совместной работы может применяться для улучшения распределенного хранения VPG, например, в плане принятия решения кэшировать содержимое локально или использовать модель совместной работы для распределения VPG-содержимого на основе ограничений места хранения. Компромисс между этими двумя подходами может заключаться в эффективности кэширования в противовес служебному сигнализированию управляющего трафика, необходимым для поддержания кэшированного режима экземпляров VPG в маршрутизаторах 412 содержимого.

Фиг. 5 изображает вариант осуществления обращения и доступа к VPG 500, который может использоваться для реализованного экземпляра VPG в CON. CON может содержать множество соединенных друг с другом маршрутизаторов 512 содержимого, которые могут соединяться с множеством узлов 514, ассоциированных с отдельными пользователями и множеством клиентских пунктов 516, которое может служить в качестве группы пользователей, как, например, в предприятии или социальной сети. Клиентские узлы 514 и клиентские пункты 516 могут конфигурироваться аналогично соответствующим вышеописанным компонентам. Клиентские узлы 514 могут осуществлять связь с маршрутизаторами 512 содержимого и/или клиентскими пунктами 516 через множество сетей 520 доступа. Клиентские узлы 514 и клиентские пункты 516 могут соответствовать множеству VPG.

Обращение и доступ к VPG 500 может использоваться для обеспечения подходящей ассоциации взаимодействия, исходящего из VPG (например, в плоскостях администрирования, управления и данных), с экземпляром VPG на маршрутизаторах 512 содержимого. Это может требовать идентификации потоков публикации/запросов и данных, относящихся к экземпляру VPG в каждом маршрутизаторе 512 содержимого, ассоциированном с экземпляром VPG. Это может быть достигнуто путем ассоциации множества VPG-ID с соответствующими экземплярами VPG на маршрутизаторах 512 содержимого. Для дальнейшего управления служебным доступом VPG-ID может связываться с ID пользователей или участников, ассоциированными с VPG-пользователями, например, клиентскими узлами 514 и/или клиентскими пунктами 516. Этот уровень управления может обеспечивать возможность установки списков управления доступом (ACL) на каждый экземпляр VPG. Дополнительно другие ID сетевого уровня могут использоваться оператором CON для различения экземпляров VPG. Такие ID могут требоваться для функционирования плоскости управления и плоскости данных в рамках контекста CON.

Фиг. 6 изображает вариант осуществления виртуализации 600 плоскости администрирования VPG, которая может использоваться в плоскости администрирования для поддержания операций для реализованного экземпляра VPG в CON. CON может содержать множество соединенных друг с другом маршрутизаторов 612 содержимого, множество клиентских узлов 614, множество клиентских пунктов 616 и множество сетей 620 доступа, которые могут конфигурироваться по существу аналогично соответствующим вышеописанным компонентам. Клиентские узлы 614 могут быть соединены непосредственно с клиентскими пунктами 616, которыми могут быть клиентские операторы или провайдеры содержимого для клиентских узлов 614, или через сети 620 доступа, как показано на фиг. 6. Клиентские узлы 614 и клиентские пункты 616 могут соответствовать множеству VPG. Соответствующие экземпляры VPG, предоставленные на маршрутизаторах 612 содержимого, указаны на Фиг. 6 множеством эллипсов, которые имеют различный шаблон заполнения. В виртуализации 600 плоскости администрирования VPG пользователь (например, клиентский узел 614) или клиентский оператор VPG (например, клиентский пункт 616) могут администрировать политиками, которые определяют функционирование VPG. Политики, администрирование которыми осуществляется, могут основываться на администрировании политиками и SLA-администрировании.

Администрирование политиками может содержать дифференцирующие политики в отношении привилегий, которыми наделяется участник VPG относительно оператора VPG на стороне клиента. Взаимодействие, относящееся к администрированию, с VPG может авторизоваться подходящими политиками защиты с учетом этих привилегий. Привилегии администрирования, относящегося к участнику, могут изначально устанавливаться клиентским оператором. Для взаимодействия, относящегося к участнику, первый этап авторизации может осуществляться клиентом, который может обеспечивать возможность тонкой дифференциации привилегий между участниками VPG. Этот первый этап администрирования взаимодействия может авторизоваться VPG-клиентом и впоследствии CON. Клиентский оператор может иметь возможность определять политики в рамках SLA-параметров, которые согласованы между VPG и провайдерами служб. Любая политика, определенная оператором, может применяться ко всем экземплярам VPG в CON. Это может быть достигнуто с использованием централизованного объекта 610 или децентрализованного механизма.

В централизованном подходе VPG-клиент, например, клиентский узел 614, может инициировать изменения политик путем взаимодействия с первым транзитным CON-посредником, например, маршрутизатором 612 содержимого на границе CON. Клиентский узел 614 может отправлять одну или несколько политик, требуемых действий, VPG-ID и ID оператора (для клиентских операторов или клиентских пунктов 616) или ID участников (для клиентских узлов 514) к CON-посреднику для инициации изменений политик. CON-посредник затем может перенаправить запрос к централизованному объекту 610, которым может являться администратор VPG на стороне CON, для идентификации экземпляров VPG в CON и сообразного применения соответствующих политик для всех экземпляров VPG. Централизованный подход дополнительно может быть расширен для взаимодействий участников, где политики, определяемые участниками (например, политики группы внутри VPG), могут применяться для всех экземпляров VPG. Альтернативно децентрализованный подход может осуществляться, в котором плоскость управления VPN может подвергаться воздействию для распространения и синхронизации политик для всех экземпляров VPG.

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

Виртуализация 600 плоскости администрирования VPG может содержать функции администрирования уровня для каждой VPG, например, для обращения VPG, предоставления и администрирования VPG. Обращение VPG может использовать уникальные глобальные идентификаторы, которые могут содержать множество поддающихся проверке VPG-ID для экземпляров VPG и дополнительные идентификаторы, например, на уровне пользователей/служб, такие как ID клиентского оператора и/или ID участника, которые могут требоваться на основе определения службы VPG и обращения к содержимому VPG. Обращение VPG может находиться в соответствии с семантикой наименования или любыми другими конструкциями индивидуального наименования. Таким образом, взаимодействия с VPG могут снабжаться метками для виртуального или физического разделения VPG-взаимодействий в администрировании SLA-политиками ICN, например, статичное или динамическое согласование и обеспечение исполнения. Обращение VPG может использоваться в параметрах безопасности для пользовательской конфиденциальности (например, обработки личных и конфиденциальных данных), аутентификации пользователя, целостности данных, операторской политике, аутентификации/авторизации доступа, ресурсе плоскости содержимого (например, хранения и вычисления), готовности (например, дублирования) и надежности (например, времени бездействия, политик отказоустойчивости/защитного переключения, горячих резервов). Обращение VPG может использоваться в конфигурировании ресурсов плоскости транспортировки, ассоциированных с QoS (например, времени отклика и полосы частот), точки локального исправления (PLR) и/или времени ожидания. Обращение VPG также может использоваться для надежности служебного API (например, операций публикации, запроса, модификации и/или стирания). Предоставление может содержать реализацию VPG, например, для удовлетворения VPG-требований и оптимизационной задачи, как описано выше, и учетных операций, например, для получения статистики пользовательского трафика и тарификации для служб. Администрирование VPG может содержать администрирование пользователя в зависимости от VPG-оператора в зависимости от привилегий SP ICN, и служебных API, управление которыми может выполняться посредством сетевого пользовательского интерфейса (UNI) для инициации изменений в VPG. Администрирование VPG-службой может центральным образом осуществлять SP ICN. В одном варианте осуществления администрирование VPG может основываться на бизнес-модели, в которой управление реализованными экземплярами может выполняться соответствующими VPG.

Фиг. 7 изображает вариант осуществления виртуализации 700 плоскости хранения и вычисления VPG, которая может использоваться для поддержания хранения/кэширования для множества экземпляров VPG в плоскости хранения и вычисления в CON. CON может содержать множество соединенных друг с другом маршрутизаторов 712 содержимого, множество клиентских узлов 714 и множество сетей 720 доступа, которые могут конфигурироваться по существу аналогично соответствующим вышеописанным компонентам.

В виртуализации 700 плоскости хранения и вычисления VPG хранение и вычисление может быть распределено в CON согласно тому, как были реализованы соответствующие VPG. Каждый маршрутизатор 712 содержимого, который содержит режим VPG, может иметь предоставленный или виртуализированный закрытый ресурс хранения и вычисления для этой VPG. Однако хранение содержимого и вычисление может не требоваться во всех экземплярах VPG на всех маршрутизаторах 712 содержимого. К примеру, содержимое для одной VPG (VPG-A) может быть распределено на основе вычисления и храниться на граничных маршрутизаторах 712 содержимого, но не на центральных маршрутизаторах 712 содержимого. Дополнительные политики могут применяться над ресурсами хранения и вычисления для приоритезации их использования между содержимым и приложениями VPG. На основе логических функций плоскости управления пользовательские запросы на публикацию/подписку содержимого (например, с использованием VPG-ID) могут подвергаться воздействию или пользоваться готовностью распределенного ресурса хранения и вычисления для максимизации или улучшения эффективности распространения содержимого. Централизованный режим разрешения содержимого, например, в централизованном объекте CON, может зависеть от VPG-архивов, например, локальных хранилищ/кэшей в маршрутизаторе 712 содержимого, для хранения/кэширования и извлечения частей или порций распределенного содержимого по маршрутизаторам 712 содержимого. Такая схема разрешения распределенного содержимого может быть оптимизирована для статичного содержимого. В этом случае динамическое содержимое может быть разделено на части перед извлечением. Альтернативно децентрализованный режим может исследовать экземпляры VPG для разрешения содержимого и обрабатывать все содержимое как динамическое содержимое.

Фиг. 8 изображает вариант осуществления виртуализации 800 плоскости управления VPG, которая может использоваться для администрирования обмена протокольными сообщениями плоскости управления для множества экземпляров VPG в управляющей плоскости в CON 810. Обмен протокольными сообщениями может относиться к публикации/запрашиванию содержимого, маршрутизации, разрешению имен, совместному кэшированию и/или другим протоколам для обеспечения возможности эффективного распространения содержимого. CON 810 может содержать множество маршрутизаторов 812 содержимого, соединенных с множеством клиентских узлов/пунктов 814, которые могут конфигурироваться, как описано в вышеприведенных вариантах осуществления. К примеру, виртуализация 800 плоскости управления VPG может администрировать множество обменов протокольными сообщениями для первой VPG (VPG-A), второй VPG (VPG-B) и третьей VPG (VPG-C). Таким образом, маршрутизаторы 812 содержимого могут устанавливать три раздельных режима VPG для каждого соответствующего реализованного VPG. Режимы VPG могут содержать первый режим VPG (A) для VPG-A, второй режим VPG (B) для VPG-B и первый режим VPG (C) для VPG-C. В частности, маршрутизаторы 812 содержимого, посредством которых экземпляры VPG были реализованы, могут устанавливать соответствующий экземпляр управляющего протокола для каждого из экземпляров VPG. К примеру, маршрутизаторы 812 содержимого могут устанавливать первый экземпляр 840 управляющего протокола для VPG-A, второй экземпляр 850 управляющего протокола для VPG-B и третий экземпляр 860 управляющего протокола для VPG-C.

Виртуализация 800 плоскости управления VPG может использоваться для администрирования протокольным обменом плоскости управления между одним и тем же экземпляром VPG, распределенным по CON 810, например, по маршрутизаторам 812 содержимого. Обмен сообщениями может содержать множество функций, относящихся к администрированию VPG-политик, ресурсам кэширования, администрированию разрешения имен, таблице перенаправления содержимого, дублированию и администрированию соответствия данных в контексте VPG. Таким образом, множество дублированных экземпляров плоскости управления (во множестве маршрутизаторов 812 содержимого) может использоваться для каждой VPG, что может обеспечивать по существу полную изоляцию между экземплярами VPG и обменами и относительно простое предоставление, но может приводить к чрезмерному служебному сигнализированию. К примеру, виртуализация 800 плоскости управления VPG может использовать распределенную хэш-таблицу (DHT) для каждого экземпляра VPG для обработки действий публикации/запроса пользователя, которые требуют подходящего индексирования содержимого и разрешения имен. С использованием такого подхода плоскости управления для каждой VPG множество экземпляров DHT может быть создано для каждой VPG. В этом случае каждый экземпляр VPG-DHT может работать независимо от других. Недостаток этого подхода состоит в служебном сигнализировании, ассоциированном с множеством экземпляров DHT-протокола.

Фиг. 9 изображает вариант осуществления другой виртуализации 900 плоскости управления VPG, которая может использоваться для администрирования обменом протокольными сообщениями для множества экземпляров VPG в управляющей плоскости в CON 910. CON 910 может содержать множество маршрутизаторов 912 содержимого, соединенных с множеством клиентских узлов/пунктов 914, которые могут конфигурироваться, как описано в вышеприведенных вариантах осуществления. К примеру, виртуализация 900 плоскости управления VPG может администрировать множество обменов протокольными сообщениями для первой VPG (VPG-A), второй VPG (VPG-B) и третьей VPG (VPG-C). Таким образом, маршрутизаторы 912 содержимого могут устанавливать три раздельных режима VPG для каждого соответствующего реализованного экземпляра VPG. Режимы VPG могут содержать первый режим VPG (A) для VPG-A, второй режим VPG (B) для VPG-B и первый режим VPG (C) для VPG-C. В частности, маршрутизаторы 912 содержимого, посредством которых экземпляры VPG были реализованы, могут устанавливать один экземпляр 940 протокола для всех экземпляров VPG. Маршрутизаторы 912 содержимого могут подходящим образом демультиплексировать сообщения протокольного обмена для VPG-A, VPG-B и VPG-C на основе отдельных VPG-ID, ассоциированных с различными режимами VPG A, B и C или экземплярами.

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

Фиг. 10 иллюстрирует вариант осуществления другой виртуализации 1000 плоскости управления VPG, которая может использоваться для администрирования обмена протокольными сообщениями для множества экземпляров VPG в плоскости управления в CON 1010. CON 1010 может содержать множество маршрутизаторов 1012 содержимого, соединенных с множеством клиентских узлов/пунктов 1014, которые могут конфигурироваться, как описано в вышеприведенных вариантах осуществления. К примеру, виртуализация 1000 плоскости управления VPG может администрировать множество обменов протокольными сообщениями для первой VPG (VPG-A), второй VPG (VPG-B) и третьей VPG (VPG-C) (VPG-B и VPG-C не показаны). Таким образом, маршрутизаторы 1012 содержимого могут устанавливать три раздельных режима VPG для каждого соответствующего реализованного экземпляра VPG, содержащих первый режим VPG (A) для VPG-A, второй режим VPG (B) для VPG-B и первый режим VPG (C) для VPG-C.

В частности, маршрутизаторы 1012 содержимого могут устанавливать соответствующий экземпляр управляющего протокола для каждого из экземпляров VPG с использованием парадигм маршрутизации содержимого на основе префиксов. Каждый маршрутизатор 1012 содержимого может содержать множество экземпляров VPG с использованием состояния таблицы ожидания, кэшированных данных и данных перенаправления для каждого экземпляра для обработки интересующих пакетов. Маршрутизаторы 1012 содержимого могут использовать протоколы маршрутизации, такие как "предпочтение кратчайшего пути" (OSPF) и/или "промежуточная система - промежуточная система" (IS-IS), чтобы обеспечить возможность каждому экземпляру VPG администрировать таблицы перенаправления. Маршрутизаторы 1012 содержимого могут устанавливать виртуальную базу информации перенаправления (VFIB) для каждого экземпляра VPG, чтобы обрабатывать перенаправление пакетов для каждого экземпляра. В некоторых вариантах осуществления маршрутизатор 1012 содержимого также может использовать алгоритмы для маршрутизации содержимого, разрешения имен и/или выборки серверов для каждого экземпляра VPG, который удовлетворяет соответствующим VPG-требованиям. К примеру, выборка серверов (выбор серверов и сетевых путей) для каждой VPG может различаться, и, таким образом, маршрутизатор 1012 содержимого может использовать соответствующий специализированный алгоритм выборки серверов для каждой VPG.

Фиг. 11 изображает вариант осуществления другой виртуализации 1100 плоскости управления VPG, которая может использоваться для администрирования обмена протокольными сообщениями для множества экземпляров VPG в плоскости управления в CON 1110. CON 1110 может содержать множество маршрутизаторов 1112 содержимого, соединенных с множеством клиентских узлов/пунктов 1114, которые могут конфигурироваться, как описано в вышеприведенных вариантах осуществления. К примеру, виртуализация 1100 плоскости управления VPG может администрировать множество обменов протокольными сообщениями для первой VPG (VPG-A), второй VPG (VPG-B) и третьей VPG (VPG-C) (VPG-B и VPG-C не показаны). Таким образом, маршрутизаторы 1112 содержимого могут устанавливать три раздельных режима VPG для каждого соответствующего реализованного экземпляра VPG, содержащих первый режим VPG (A) для VPG-A, второй режим VPG (B) для VPG-B и первый режим VPG (C) для VPG-C. В частности, маршрутизаторы 1112 содержимого могут устанавливать один экземпляр 1140 управляющего протокола для всех экземпляров VPG с использованием парадигм маршрутизации содержимого на основе префиксов. Каждый маршрутизатор 1112 содержимого может содержать одно состояние таблицы ожидания, кэшированных данных и данных перенаправления для всех экземпляров VPG для обработки интересующих пакетов. Таким образом, маршрутизаторы 1112 содержимого могут использовать схему демультиплексирования для маршрутизации протокольных сообщений к подходящим экземплярам VPG.

Фиг. 12 изображает вариант осуществления виртуализации 1200 плоскости данных VPG, которая может использоваться для обработки данных содержимого, принимаемых и передаваемых для множества экземпляров VPG в плоскости данных или данных содержимого в CON 1210. CON 1210 может содержать множество маршрутизаторов 1212 содержимого, соединенных с множеством клиентских узлов/пунктов 1214, которые могут конфигурироваться, как описано в вышеприведенных вариантах осуществления. К примеру, виртуализация 1200 плоскости данных VPG может обрабатывать данные содержимого для первой VPG (VPG-A), второй VPG (VPG-B) и третьей VPG (VPG-C). Таким образом, маршрутизаторы 1212 содержимого могут устанавливать три раздельных режима VPG для каждого соответствующего реализованного экземпляра VPG, содержащих первый режим VPG (A) для VPG-A, второй режим VPG (B) для VPG-B и первый режим VPG (C) для VPG-C.

Данные содержимого могут соответствовать как интересу пользователя, проистекающему из VPG, так и пакетам отклика данных, соответствующим изъявленным интересам. Части или порции содержимого, обмен которыми происходит между экземплярами VPG и/или маршрутизатором 1212 содержимого, могут кодироваться с конкретными атрибутами, такими как имя содержимого, которому принадлежит часть содержимого, или VPG-ID экземпляра VPG, из которого исходит часть содержимого, или должны быть отображены на сторону приема. Такие метаданные могут использоваться для отображения принятых данных в подходящие экземпляры VPG. VPG-данные, входящие в границы CON 1210, могут быть идентифицированы маршрутизатором 1212 содержимого, поскольку они снабжены метками, демультиплексированы и обработаны в соответствующем экземпляре VPG. Разрешение запроса содержимого в местоположение и решение перенаправления также может рассматриваться в контексте экземпляра VPG. Дополнительно может быть обеспечено исполнение SLA-политик (например, для производительности, защиты, готовности и надежности) над откликами на запросы/данные интересов (например, частями содержимого) в контексте каждой VPG. Это может инициировать взаимодействие с плоскостью управления VPG.

Фиг. 13 изображает вариант осуществления виртуализации 1300 плоскости транспортировки VPG, которая обеспечивает множество экземпляров перенаправления для множества экземпляров VPG в плоскости транспортировки в CON 1210. Экземпляры перенаправления могут поддерживать досягаемость между экземплярами VPG и/или маршрутизаторами 1312 содержимого и соответствующими функциями администрирования ресурсами для транспортирования данных между экземплярами VPG/маршрутизаторами 1312 содержимого. CON может содержать множество маршрутизаторов 1312 содержимого (только один показан), соединенных с множеством клиентских узлов/пунктов 1314, которые могут конфигурироваться, как описано в вышеприведенных вариантах осуществления. К примеру, виртуализация 1300 плоскости транспортировки VPG может установить экземпляры перенаправления для первой VPG 1341 (VPG-A), второй VPG 1342 (VPG-B) и третьей VPG 1343 (VPG-C). Таким образом, маршрутизаторы 1312 содержимого могут устанавливать три раздельных режима VPG для каждого соответствующего созданного экземпляра VPG.

Один или более экземпляров VPG может распространяться по CON, например, по маршрутизаторам 1312 содержимого. Сетевые узлы, например маршрутизаторы 1312 содержимого, могут конфигурироваться для демультиплексирования поступающих частей содержимого и/или обменов управляющими сообщениями различных экземпляров VPG. Плоскость содержимого CON или ICN может быть осведомленной о плоскости транспортировки, например, осведомленной о функциях плоскости транспортировки. Для поступающего трафика плоскость содержимого может конфигурироваться для отображения существующих конструкций виртуализации транспортировки, таких как конструкции таблицы маршрутизации и перенаправления VPN (VRF), виртуального маршрутизатора (VR) и/или службы виртуальной закрытой локальной сети (VPLS), которые могут использоваться в текущих сетях или технологиях.

К примеру, VPG-A 1341, VPG-B 1342 и VPG-C 1343 в плоскости 1340 данных содержимого могут быть отображены в соответствующие экземпляр 1351 VRF/VPG-1, экземпляр 1352 VRF/VPG-2 и экземпляр 1353 VRF/VPG-3 соответственно в плоскости транспортировки с использованием подходящих конструкций, требуемых для отображения трафика в правильный VRF-экземпляр. Маршрутизатор 1312 содержимого может принимать множество пакетов, ассоциированных с VPG-A, VPG-B и VPG-C, в физическом уровне 1370 транспортировки. Принятые пакеты могут обрабатываться виртуализированной функцией 1360 администрирования ресурсами VPG и затем демультиплексироваться виртуализированным демультиплексором 1350 VPG. Пакеты могут демультиплексироваться должным образом в соответствующие экземпляр 1351 VRF/VPG-1, экземпляр 1352 VRF/VPG-2 и экземпляр 1353 VRF/VPG-3, например, в плоскости транспортировки. Экземпляры плоскости транспортировки затем могут быть должным образом отображены в экземпляры VPG-A 1341, VPG-B 1342 и VPG-C 1343 плоскости содержимого.

Для исходящего трафика экземпляры VPG-A 1341, VPG-B 1342 и VPG-C 1343 плоскости содержимого также могут быть отображены в экземпляр 1351 VRF/VPG-1, экземпляр 1352 VRF/VPG-2 и экземпляр 1353 VRF/VPG-3 плоскости транспортировки обратным образом. На уровне перенаправления маршрутизаторы 1312 содержимого могут конфигурироваться для добавления политик для обработки различных запросов/откликов содержимого другим образом. Взаимодействие в плоскости содержимого между любыми двумя маршрутизаторами содержимого может быть отображено в их соответствующую виртуализацию уровня транспортировки так, что трафик для экземпляра VPG может проходить через правильный экземпляр в плоскости транспортировки. Отображение виртуализации плоскости содержимого обеспечивает возможность расширения виртуализации от уровня приложений до уровня транспортировки.

Виртуализация плоскости транспортировки может быть осуществлена посредством VPN, предоставленной провайдером. Этот уровень виртуализации может обеспечивать для множества VPN возможность конфигурации и администрирования провайдерами служб VPN. Характеристики, обеспечиваемые такой службой, могут содержать виртуальное разделение управления и транспортировки данных между содержащимися VPN, персонально настроенной организации трафика (TE) и QoS для удовлетворения отдельных нужд VPN и защиты данных, проходящих между VPN-пунктами. VPN-виртуализация может поддерживаться на уровне три (L3) и уровне два (L2) модели взаимодействия открытых систем (OSI). Виртуализация плоскости содержимого может быть логически соединена с виртуализацией плоскости транспортировки, как описано выше, так, что персональная настройка может быть расширена до всех уровней модели OSI. В этом случае, вдобавок к персональной настройке распространения содержимого VPG также может согласовывать SLA для свойства возможности подключения плоскости транспортировки в плоскости транспортировки. SLA-параметры могут содержать топологию/возможность подключения VPN и QoS-характеристиками на основе трафика, предлагаемого между пунктами. Это соединение между плоскостью содержимого и плоскостью транспортировки может обеспечить необходимые условия для персонально настроенной совместной оптимизации TE и SS в рамках контекста VPG.

Фиг. 14 изображает вариант осуществления способа защиты 1400 CON, который может использоваться для обеспечения целостности и конфиденциальности содержимого. Способ защиты CON может осуществляться CON, центральным средством управления CON, одним или несколькими маршрутизаторами содержимого или комбинациями перечисленного. Способ защиты 1400 CON может основываться на любой из схем уровня защиты, описанных выше, например, на основе классификации пользователя или группы пользователей, одном из режимов работы, описанных выше, или и том, и другом. Способ 1400 может начинаться в блоке 1410, где подписанное содержимое может быть принято в CON, например, маршрутизатором содержимого. Принятое содержимое может подписываться и публиковаться пользователем или издателем. Пользователь или издатель может соответствовать одной или нескольким группам пользователей и может подписывать содержимое с использованием подписи "pr-p". Содержимое может публиковаться без гарантии конфиденциальности от CON, защищенным образом публиковаться для обеспечения конфиденциальности или защищенным образом публиковаться для авторизованных групп пользователей (с использованием групповых ID).

CON-защита 1400 может поддерживать одну или несколько VPG на множестве доменов с использованием принципа обменных пунктов или путем расширения междоменных протоколов, таких как протокол шлюзов внешних границ (E-BGP), для работы на пиринговых точках с подходящими расширениями для обработки информации, специфичной для VPG. Это также может требовать подходящего SLA-согласования для удовлетворения требований VPG. Протоколы управления могут быть расширены для обмена опубликованной информацией от VPG-участников на доменных границах. Таким образом, информация, полученная из другого домена, также может ассоциироваться с конкретными политиками перед оглашением информации в локальном домене. Это может обеспечивать возможность принятия решений распространения содержимого со знанием, что экземпляры VPG существуют вне локального CON-домена. Дополнительно служебная гарантия также может быть расширена на пиринговые точки путем предоставления подходящих ресурсов полосы частот, хранения и вычисления для VPG-трафика, пересекающего пиринговые точки.

Участники VPG также могут иметь возможность доступа к VPG-службам, даже когда они мобильны. Это может не требовать каких-либо специальных существенных расширений с точки зрения конструкций, которые могут использоваться CON для обеспечения возможности мобильности в сценарии без VPG. Конструкции, схемы и способы, описанные в предварительной патентной заявке США № 61/439769, поданной 4 февраля 2011 г. Го-Цзян Ваном (Guo-Qiang Wang) и др. и озаглавленной "Method and Apparatus for a Control Plane to Manage Domain-Based Security, Mobility and Social Groups in a Content Oriented Network", которая включена сюда посредством ссылки, могут подвергаться воздействию для разрешения мобильных узлов в другом домене и обеспечения исполнения политик базового домена во внешних доменах. Эти конструкции, схемы и способы могут объединяться с концепциями виртуализации ресурсов для каждой VPG для обеспечения защищенного и служебно-гарантированного распространения информации среди мобильных участников VPG.

В блоке 1420 подписанное содержимое может кэшироваться/храниться в CON. Содержимое может шифроваться перед кэшированием/хранением, например, маршрутизатором содержимого. Содержимое может шифроваться с использованием ключа шифрования k, групповых ID или политик. Зашифрованное содержимое также может быть подписано с использованием подписи "pr-c". В блоке 1430 запрос содержимого может быть принят в CON, например, тем же или вторым маршрутизатором содержимого. Содержимое может быть принято от пользователя или подписчика в той же группе пользователей или другой группе пользователей, авторизованной на получение содержимого. В блоке 1440 запрашиваемое содержимое может быть перенаправлено. Маршрутизатор содержимого может перенаправлять кэшированное/хранимое содержимое к подписчику. Если кэшированное/хранимое содержимое шифруется, то маршрутизатор содержимого может дешифровать содержимое с использованием ключа шифрования k или групповых ID. Подписчик и опционально маршрутизатор содержимого также может подтверждать содержимое перед получением содержимого. Способ 1400 затем может заканчиваться.

Фиг. 15 изображает вариант осуществления сетевого блока 1500, который может быть любым устройством, которое транспортирует и обрабатывает данные через сеть. К примеру, сетевой блок 1500 может располагаться в маршрутизаторе содержимого, или любом узле в CON 100, или любом узле в CON-схемах, описанных выше. Маршрутизатор содержимого также может конфигурироваться для осуществления или поддержки способа 1400 защиты CON, описанного выше. Сетевой блок 1500 может содержать один или несколько входных портов или блоков 1510, соединенных с приемником (Rx) 1512, для приема сигналов и кадров/данных от других сетевых компонентов. Сетевой блок 1500 может содержать блок 1520 осведомленности о содержимом для определения, какому из сетевых компонентов отправить содержимое. Блок 1520 осведомленности о содержимом может осуществляться с использованием аппаратных средств, программных средств или и того, и другого. Сетевой блок 1500 также может содержать один или несколько выходных портов или блоков 1530, соединенных с передатчиком (Tx) 1532, для передачи сигналов и кадров/данных другим сетевым компонентам. Приемник 1512, блок 1520 осведомленности о содержимом и передатчик 1532 также могут конфигурироваться для осуществления по меньшей мере некоторых из раскрываемых способов, которые могут основываться на аппаратных средствах, программных средствах или и том, и другом. Компоненты сетевого блока 1500 могут осуществляться, как показано на фиг. 15.

Блок 1520 осведомленности о содержимом также может содержать программируемый блок 1528 плоскости перенаправления содержимого и один или несколько блоков 1522 хранения, которые могут соединяться с программируемым блоком 1528 плоскости перенаправления содержимого. Программируемый блок 1528 плоскости перенаправления содержимого может конфигурироваться для осуществления функций перенаправления и обработки содержимого, таких как на уровне приложений или L3, где содержимое может перенаправляться на основе имени или префикса содержимого и, возможно, другой информации, относящейся к содержимому, которые отображают содержимое в сетевой трафик. Такая информация отображения может содержаться в таблице содержимого в блоке 1520 осведомленности о содержимом или сетевом блоке 1500. Программируемый блок 1528 плоскости перенаправления содержимого может интерпретировать пользовательские запросы на содержимое и соответственным образом извлекать содержимое, например, на основе метаданных и/или имени содержимого, из сети или других маршрутизаторов содержимого и может сохранять содержимое, например, временно, в блоках 1522 хранения. Программируемый блок 1528 плоскости перенаправления содержимого затем может перенаправлять кэшированное содержимое пользователю. Программируемый блок 1528 плоскости перенаправления содержимого может осуществляться с использованием программных средств, аппаратных средств или и того, и другого, и может работать над IP-уровнем или L2. Блоки 1522 хранения могут содержать кэш 1524 для временного хранения содержимого, такого как содержимое, которое запрашивается подписчиком. Дополнительно блоки 1522 хранения могут содержать долговременное хранилище 1526 для хранения содержимого относительно дольше, такого как содержимое, предоставляемое издателем. К примеру, кэш 1524 и долговременное хранилище 1526 могут включать в себя динамические оперативные запоминающие устройства (DRAM), твердотельные накопители (SSD), жесткие диски или комбинации перечисленного.

Сетевые компоненты, описанные выше, могут осуществляться на любом универсальном сетевом компоненте, таком как компьютер или сетевой компонент, с достаточной вычислительной мощностью, ресурсами памяти и пропускной способностью сети для обслуживания необходимой загруженности, возложенной на него. Фиг. 16 изображает типичный универсальный сетевой компонент 1600, подходящий для осуществления одного или нескольких вариантов осуществления компонентов, раскрываемых здесь. Сетевой компонент 1600 включает в себя процессор 1602 (который может называться центральным процессором или CPU), который связан с запоминающими устройствами, включая вторичное хранилище 1604, постоянное запоминающее устройство (ROM) 1606, оперативное запоминающее устройство (RAM) 1608, устройства 1610 ввода/вывода (I/O) и устройства 1612 сетевых подключений. Процессор 1602 может осуществляться как одной или несколькими CPU-микросхемами или может входить в состав одной или нескольких специализированных интегральных цепей (ASIC).

Вторичное хранилище 1604, как правило, состоит из одного или нескольких дисковых накопителей или ленточных накопителей и используется для энергонезависимого хранения данных и в качестве устройства хранения данных переполнения, если RAM 1608 недостаточно велико для содержания всех рабочих данных. Вторичное хранилище 1604 может использоваться для хранения программ, которые загружены в RAM 1608, когда такие программы выбираются для исполнения. ROM 1606 используется для хранения инструкций и, возможно, данных, которые считываются во время исполнения программы. ROM 1606 является энергонезависимым запоминающим устройством, которое, как правило, имеет небольшой объем памяти по отношению к большему объему памяти вторичного хранилища 1604. RAM 1608 используется для хранения энергозависимых данных и, возможно, для хранения инструкций. Доступ к ROM 1606 и RAM 1608, как правило, быстрее, чем к вторичному хранилищу 1604.

Раскрывается по меньшей мере один вариант осуществления, и вариации, комбинации и/или модификации согласно варианту(ам) осуществления и/или признаки согласно варианту(ам) осуществления, производимому обычным специалистом в данной области техники, не выходят за пределы объема раскрытия. Альтернативные варианты осуществления, которые являются результатом комбинирования, объединения и/или исключения признаков согласно варианту(ам) осуществления, также не выходят за пределы объема раскрытия. Когда числовые диапазоны или ограничения особым образом указываются, такие особые диапазоны или ограничения должны пониматься как включающие в себя многократные диапазоны или ограничения подобных величин, попадающие в особым образом указанные диапазоны или ограничения (например, "от примерно 1 до примерно 10" включает в себя, 2, 3, 4 и т. д.; "больше 0,10" включает в себя 0,11, 0,12, 0,13 и т. д.). К примеру, когда числовой диапазон с нижней границей, R_н, и верхней границей, R_в, описывается, любое число, попадающее в диапазон, конкретным образом описывается. В частности, следующие числа внутри диапазона конкретным образом описываются: R=R_н+k×(R_в-R_н), причем k является переменной, изменяющейся от 1 процента до 100 процентов с шагом в 1 процент, т. е. k равно 1 процент, 2 процента, 3 процента, 4 процента, 7 процентов, ..., 70 процентов, 71 процент, 72 процента, ..., 97 процентов, 96 процентов, 97 процентов, 98 процентов, 99 процентов или 100 процентов. Кроме того, любой числовой диапазон, определенный двумя R-числами, определенными выше, также конкретным образом описывается. Использование термина "опционально" по отношению к любому элементу формулы означает, что элемент требуется или альтернативно элемент не требуется, причем обе альтернативы находятся в рамках объема формулы. Использование более широких терминов, таких как "содержит", "включает в себя" и "имеющий", должно пониматься как обеспечивающее поддержку для более узких терминов, таких как "состоящий из", "состоящий по существу из" и "по существу содержащий". Соответственным образом объем охраны не ограничивается описанием, изложенным выше, а определяется пунктами формулы, которые следуют далее, причем объем включает в себя все эквиваленты сущности формулы. Все без исключения пункты формулы включены в качестве дополнительного раскрытия в техническое описание, и пункты формулы являются вариантом(ами) осуществления настоящего раскрытия. Рассмотрение ссылки в раскрытии не является признанием, что это предшествующий уровень техники, в особенности любой ссылки, которая имеет более позднюю дату публикации, чем дата приоритета этого документа. Раскрытие всех патентов, патентных заявок и публикаций, упоминаемых в раскрытии, включено в настоящий документ посредством ссылки, в случаях, если они обеспечивают примерные, процедурные или другие подробности, дополняющие раскрытие.

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

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

Claims (17)

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

2. Маршрутизатор содержимого по п. 1, в котором пользователи соответствуют одной группе пользователей или множеству групп пользователей, которые имеют по меньшей мере одно из множества соответствующих политик администрирования/распространения содержимого, политик защиты, множества соглашений об уровне обслуживания (SLA), множества требований качества обслуживания (QoS) и множества других политик.

3. Маршрутизатор содержимого по п. 1, в котором клиент соответствует множеству групп пользователей, которые авторизованы совместно использовать содержимое.

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

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

6. Маршрутизатор содержимого по п. 1, в котором одно и то же содержимое кэшируется множество раз с использованием множества идентификаторов групп (ID) для множества групп пользователей, которые авторизованы совместно использовать содержимое.

7. Маршрутизатор содержимого по п. 1, в котором содержимое кэшируется однократно с использованием политики для множества групп пользователей, которые авторизованы совместно использовать содержимое.

8. Маршрутизатор содержимого по п. 1, в котором пользователи используют множество алгоритмов шифрования для подписания и верификации содержимого.

9. Маршрутизатор содержимого по п. 1, в котором пользователи используют множество интерфейсов программирования приложений (API) для публикации и подписки на содержимое.

10. Маршрутизатор содержимого по п. 1, в котором CON использует множество функций для шифрования и дешифрования содержимого, которые прозрачны для пользователей.

11. Маршрутизатор содержимого по п. 1, в котором различные уровни защиты предназначены для по меньшей мере одного из целостности, конфиденциальности и совместного использования содержимого.

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

13. Система CON по п. 12, в которой подписанное содержимое подписывается издателем с использованием закрытого ключа издателя, и причем подписанное содержимое, которое отправляется из кэша подписчику, верифицируется подписчиком с использованием открытого ключа подписчика.

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

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

16. Система CON по п. 12, в которой подписанное содержимое шифруется с использованием логической групповой политики, которая указывает множество групп пользователей, авторизованных совместно использовать и подписываться на содержимое, и причем кэшированное содержимое дешифруется с использованием упомянутой групповой политики перед отправлением кэшированного содержимого к подписчику в одной из групп пользователей, которые удовлетворяют логической групповой политике.

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

Images