Способ и устройство для благоприятного для сети совместного кэширования

Способ и устройство для благоприятного для сети совместного кэширования

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение относится к технологиям связи, и в частности - к способу и устройству для благоприятного для сети совместного кэширования.

УРОВЕНЬ ТЕХНИКИ

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

Фиг. 2 - схематическое представление варианта осуществления схемы распределенного TE и совместного кэширования.

Фиг. 3 - схематическое представление другого варианта осуществления сетевой архитектуры.

Фиг. 4 - схематическое представление варианта осуществления средства кэширования.

Фиг. 5 - последовательность операций варианта осуществления способа кэширования.

Фиг. 6 - график варианта осуществления результатов моделирования совместного кэширования.

Фиг. 7 - график другого варианта осуществления результатов моделирования совместного кэширования.

Фиг. 8 - график другого варианта осуществления результатов моделирования совместного кэширования.

Фиг. 9 - карта варианта осуществления результатов моделирования использования сети.

Фиг. 10 - карта другого варианта осуществления результатов моделирования использования сети.

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

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

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

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

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

В предположениях для формулировки задачи оптимизации (для TE и CC) множество критериев оптимизации сети и услуг можно рассматривать для одного провайдера сетевых услуг. Провайдер сетевых услуг может содержать и иметь множество узлов CONA. Узлы CONA могут соединяться друг с другом в обычной неиерархической модели сети. Обычная неиерархическая модель сети может также включать в себя случай иерархической модели сети. Сетевые требования могут содержать балансировку нагрузки и стоимость линии связи с кусочно-линейной характеристикой. Балансировку нагрузки можно устанавливать в соответствии с формулировкой задачи оптимизации, с распределенным алгоритмом и CC, как описано дополнительно ниже. Множество узлов CONA можно также группировать или кластеризовать и обрабатывать как один логический узел, например, когда множество узлов мультиплексора доступа к цифровой абонентской линии (DSLAM) CONA подключено через коммутатор Ethernet. Объединенная сеть может содержать множество подсистем, например, подсистему маршрутизации, подсистему кэширования и/или другие подсистемы. У каждой подсистемы может быть соответствующее требование оптимизации. Однако, общая цель работы всей сети может быть непротиворечивой, причем требования различных подсистем не могут находиться в противоречии друг с другом, например, в соответствии с конструкцией и/или осуществлением.

Фиг. 1 показывает вариант осуществления сетевой архитектуры 100, который может быть сконфигурирован в общем случае в «плоской» структуре. Сетевая архитектура 100 может содержать множество узлов 110-160, которые могут быть соединены друг с другом в обычной неиерархической модели сети, например, в ячеистой топологии. Соответственно, любой из узлов 110-160 может переключаться между передачей трафика напрямую или через другой узел (узлы) без иерархических ограничений или зависимостей. Сетевая архитектура 100 может соответствовать любой сети передачи данных, которая обеспечивает услуги для клиента/абонентов, которая включает в себя сети на основе Ethernet, сети на основе Интернет-протокола (IP), пассивные оптические сети (PON), сети цифровой абонентской линии (DSL), беспроводные сети, другие сети передачи данных или их комбинации. В одном из вариантов осуществления сетевая архитектура 100 может соответствовать корпоративной сети или магистральной сети, которые обычно имеют «плоскую» структуру.

Узлы 110-160 могут быть сконфигурированы для перемещения трафика или данных в сети. Трафик может содержать пакеты (например, пакеты IP), кадры (например, кадры Ethernet), сообщения, сигналы или комбинации любого одного или большего количества из вышеизложенного. Например, узлы 110-160 могут включать в себя мосты, маршрутизаторы и/или коммутаторы, которые принимают, обрабатывают и/или передают трафик в сети. Узлы 110-160 могут перемещать сетевой трафик, используя множество линий связи или маршрутов (как обозначено сплошными линиями на Фиг. 1), который может определяться, используя TE, и могут поддерживать CC по меньшей мере между некоторыми из узлов. Узлы 110-160 могут представлять узлы физического уровня, которые принимают, обрабатывают и/или передают трафик на сетевом физическом уровне. Узлы 110, 120 и 130 могут также быть сконфигурированы для перемещения контента и/или услуг, которые могут запрашивать один или большее количество конечных пользователей. Например, узлы 110, 120 и 130 могут быть узлами CONA, которые принимают, перемещают, кэшируют и обмениваются трафиком контента друг с другом (как обозначено линиями со стрелками на Фиг. 1) в сети с возможностью CONA. Узлы 110, 120 и 130 могут представлять узлы CONA, которые обрабатывают трафик в плоскости контента, и соответствующие узлы физического уровня, которые обрабатывают сетевой трафик на физических уровнях.

Контент может содержать данные, голосовую информацию, видеоинформацию, мультимедийную информацию, информацию из Интернет и/или любой контент, ориентированный на конкретное применение, например, контент, относящийся к играм. В некоторых вариантах осуществления конечный пользователь может быть любым пользовательским устройством, соединенным с сетью, например, с любым из узлов 110-160. В дополнительном варианте осуществления сетевая архитектура может соответствовать ISP (поставщику интернет-услуг), и конечный пользователь может соответствовать поставщику контента или клиенту ISP. Например, конечный пользователь может быть сопоставлен с устройством связи в доме клиента или с пользовательским устройством, таким как оптический сетевой терминал (ONU) или приемопередающее устройство сверхскоростной DSL (VDSL) в городском поселении (VTU-R). Альтернативно, конечный пользователь может соответствовать домашнему оборудованию связи, например, телевизионной приставке, стационарному персональному устройству (такому, как настольный компьютер), или мобильному персональному устройству, такому, как сотовый телефон (который включает в себя так называемые «интеллектуальные» телефоны (то есть сотовые устройства, имеющие возможность передачи голоса и данных)), ноутбук или переносное вычислительное устройство, такое, как планшетный компьютер.

В сетевой архитектуре 100 стоимость TE может быть получена из набора задач оптимизации, которые могут увеличивать эффективность сети и поддерживать CC между узлами CONA. Задачи оптимизации могут быть разработаны или сформулированы в соответствии с некоторыми требованиями или необходимыми свойствами вычислительных систем. Например, может быть необходимо, чтобы системное решение было по существу распределенным для улучшения масштабируемости данного решения в сети. Может также быть необходимо избежать использования целочисленного программирования (IP) при формулировке задач, если возможно, что может быть результатом формулировки задачи с недетерминированным полиномиальным (NP) временем. Дополнительно, может быть необходимо получить решение, которое является относительно легко наращиваемым или расширяемым для настройки новых подсистем, которые могут быть добавлены к сети. Например, новая подсистема «Облако памяти» (SC) (совокупность устройств хранения данных) может быть добавлена к объединенной подсистеме TE и подсистеме CC без необходимости значительного перепроектирования результирующей объединенной системы TE, CC и SC.

Требования TE можно рассматривать совместно для множества классов трафика в сети, например, не делая различий между различными классами трафика. Классы трафика могут содержать передачи данных между кэшами, например, между узлами 110, 120 и 130, которые могут обрабатываться аналогично другому сетевому трафику. Совместная задача TE и CC (TECC) может быть сформулирована следующим образом:

Эти шесть вышеупомянутых ограничений (помечены (1)-(6)) представляют множество ограничений для формулировки задачи TECC. Первое ограничение (например, ограничение (1)) может соответствовать требованию TE (например, балансировки нагрузки). В ограничении (1) t_ij - трафик между кэшами (из-за передачи данных от узла i к узлу j), I_e (i, j) - матрица маршрутизации (значения которой могут быть равны приблизительно единице, если линия связи e находится на прямом маршруте от i до j), c_e - физическая емкость (например, пропускная способность) линии связи e, и b_e - фоновый трафик, вызванный другими приложениями, по линии связи e. Ограничение (1) является требованием TE для балансировки нагрузки для линии связи, но могут также использоваться другие требования, такие как одна или большее количество кусочно-линейных функций стоимости линии связи для фиксации полной стоимости сети.

Ограничение (2) может гарантировать передачу данных между кэшами, например, соответствовать требованию CC. В ограничении (2) узел j может принимать объект k данных запроса с вероятностью q_j ^k. Если j не имеет локальной копии (например, y_j ^k=0, таким образом 1-y_j ^k=1), то j должен извлекать объект из другого узла i, который имеет данный контент (например, y_j ^k=1). Для любого объекта k, когда y_j ^k=1 (например, узел j имеет локальную копию) или=0 (например, узел i не имеет локальной копии), тогда передача данных между кэшами из i в j может не происходить (например, y_i ^k (1-y_j ^k)=0). Ограничение (3) может гарантировать, что копия может существовать в каком-то узле. В ограничении (3) любой объект k может быть скопирован с помощью одного или большего количества узлов. Ограничение (4) может соответствовать предельному значению объема запоминающего устройства кэша. В ограничении (4) весь объем запоминающего устройства, используемый копиями, не может превышать доступный физический объем запоминающего устройства (например, физический объем диска) узла i.

Ограничение (5) может гарантировать, что запоминающее устройство кэша является достаточно большим, так что весь объект данных может быть скопирован с помощью доступных кэшей, например, при объединении. Запоминающее устройство кэша, доступное в сетевых узлах, которые рассматривают, может быть недостаточно большим. Также один или большее количество виртуальных узлов CONA могут быть введены в соответствии с запросом (так называемое «динамическое кэширование»), например, один или большее количество серверов, которые служат источником контента. Серверы могут сохранять только соответствующие объекты и обслуживать запросы на такие сохраненные объекты. Ограничение (6) может представлять двоичную переменную, чтобы показать, хранятся или нет объекты в кэше. В ограничении (6) y_j ^k=1, если объект k хранится локально в узле i, и y_j ^k=0 иначе. Вышеизложенная задача TECC может воплощаться, используя программу квадратичного программирования.

В другом варианте осуществления упрощенная задача TECC может быть сформулирована, например, удаляя квадратичные термины в формулировке приведенной выше задачи TECC. Индикаторная переменная x_ij ^k может быть введена для представления передачи данных между кэшами (например, x_ij ^k=1, если узел i перемещает объект k в узел j). Использование индикаторной переменной может упрощать задачу TECC, которая может затем воплощаться, используя программу целочисленного программирования вместо программы квадратичного программирования. Однако формулировка TECC в соответствии с программой целочисленного программирования может все еще быть трудной для решения.

В другом варианте осуществления задачи TECC каждый узел CONA может воплощать по меньшей мере частичное кэширование, где часть объекта контента может локально кэшироваться в одном или большем количестве узлов CONA. Эта форма «распределенного кэширования» по меньшей мере части контента в одном или большем количестве локальных узлов CONA значительно улучшает производительность сети, особенно в видео- и мультимедийных приложениях. Задача TECC для частичного кэширования может быть сформулирована следующим образом:

Ограничение (12) может указывать, что когда узел j имеет локальную копию объекта k, тогда j может не извлекать тот же самый объект из других узлов. Формулировка задачи TECC для частичного кэширования может воплощаться, используя программу целочисленного программирования. Реализация частичного кэширования может использоваться для кэширования объектов видео контента. Например, каждый видеофильм может иметь продолжительность приблизительно от 1,5 до приблизительно двух часов и иметь размер в пределах от приблизительно 200 мегабайтов (Мб) до приблизительно четырех гигабайтов (Гб), например, используя кодек H.264 или аналогичное видео кодирование, и степень сжатия, приблизительно равную двум. Пользователь может смотреть первый видеофильм в течение некоторого времени и затем выполнить ускоренную перемотку вперед к последующей части в видеофильме, или переключиться на второй видеофильм до того, как посмотрит весь первый видеофильм. В таких сценариях совместное кэширование CONA может быть неэффективным, если каждый узел CONA сконфигурирован для кэширования всего видео объекта. Частичное кэширование может предоставлять возможность каждому узлу CONA сохранять часть объекта вместо всего объекта, что может быть выгодным в случае по существу больших видео объектов.

В одном из вариантов осуществления задача TECC может быть сформулирована в соответствии с индикаторной переменной x_ij ^k, которая представляет частично кэшируемую часть объекта k, который перемещают из i в j. Задача TECC может быть сформулирована следующим образом:

Ограничение (16) может гарантировать, что (a) любой объект кэшируется в сети, и (b) любой узел i может получить по существу полную копию каждого объекта из одного или большего количества других узлов. Ограничение (19) может указывать, что часть объекта k, которую узел i может загружать из j, является самое большее частью, которую i локально кэшировал (например, узел i не может обеспечивать больше контента, чем он имеет). Ограничение (20) может указывать, что каждый объект контента может делиться на части для целей сохранения и кэширования, и что размер части по меньшей мере равен s ¯ k . Когда существует остаток объекта контента (например, s_k mod s ¯ k ≠ 0 ), этот остаток можно извлекать из источника (например, из сервера контента) и его можно нигде не кэшировать в узлах CONA. Вышеуказанная формулировка задачи TECC может воплощаться, используя программу линейного программирования, которую можно проще решить, чем программу квадратичного или целочисленного программирования. Однако, воплощение ограничения (12), например, { x i j k | ∀ i , j ∈ I , k ∈ K } , в формулировке или алгоритме может быть сложным для решения, поскольку x_ij ^k не указывает, насколько различны кэшируемые части объекта, хранящиеся в двух узлах.

Так как различия между частями объекта, кэшируемыми двумя узлами, могут быть не известны, может использоваться более простая формулировка задачи. Также, задача TECC может быть сформулирована в соответствии с индикаторной переменной x_i ^k, которая представляет частично кэшируемую часть объекта k в узле i, следующим образом:

В приведенной выше формулировке для каждого объекта определяют значение в процентах, которое каждый узел CONA может кэшировать локально, но решение о том, какую часть каждый узел может кэшировать для каждого объекта, может не определяться. Соответственно, вычисляют значение в процентах от любого рассматриваемого объекта, которое каждый узел CONA может кэшировать локально. Вычисление значения в процентах от объектов, которые могут кэшироваться каждым узлом CONA, может не подходить для всех рассматриваемых объектов, так как некоторые объекты могут быть относительно большими, а другие объекты могут быть относительно маленькими. Дополнительно, некоторые объекты можно считать более важными, чем другие объекты. В таких сценариях объекты можно классифицировать в один или большее количество соответствующих классов, например, в соответствии с их уровнями важности, приоритетами (которые определяются пользователем или оператором или иным образом), размерами и/или другой классификацией. Таким образом, задача может быть повторно сформулирована, вводя концепцию «класса объекта». Приведенная выше формулировка задачи TECC может воплощаться, используя программу линейного программирования.

В другом варианте осуществления задача TECC может быть сформулирована в соответствии с первой индикаторной переменной x_ij ^k, которая представляет часть объекта k, которую посылают от узла i к узлу j, и в соответствии со второй индикаторной переменной y_i ^k, которая представляет часть объекта k, которую кэшируют с помощью узла i. Задача TECC может быть сформулирована следующим образом:

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

Таблица 1
Условные обозначения	Содержание
E	Набор всех линий связи сети, отдельные линии указаны с помощью e
K	Набор всех объектов контента, отдельные объекты указаны с помощью k, отдельные объекты упоминаются как «объекты контента» или «объекты данных» взаимозаменяемо
I	Набор узлов CONA, отдельные узлы указаны с помощью i,каждый узел может быть логическим кластером физических узлов CONA

Ie(i,j)	Индикаторная переменная линия связи-маршрут, =1 означает, что линия связи e находится на прямом маршруте от i до j
ce	Емкость линии связи e
be	Фоновый трафик по e
sk	Размер объекта k
νi	Объем (емкость запоминающего устройства) узла i CONA
yi k	Двоичная переменная, yi k=1, если узел i имеет объект k в своем локальном кэше, иначе 0
qi k	Частота использования объекта k, наблюдаемая локально узлом i (локальное представление), ∑ k ∈ K q i k − 1

Приведенные выше задачи TECC могут быть сформулированы и решены для распределения сетевых ресурсов и увеличения эффективности сети. Например, таблица 2 показывает решение, которое может быть получено, решая приведенную выше формулировку задачи TECC для сети 100 в соответствии с ограничениями (14)-(21):

Таблица 2
xij	j=1	2	3
i=123	.6.1.5	.3.4.5	.2.3.8

В приведенном выше решении могут быть сделаны два наблюдения. Во-первых, диагональный элемент в каждой строке таблицы 2 может доминировать, например, может быть больше, чем остальные элементы в строке, так как часть объекта, которую каждый узел может обеспечивать к другим узлам, не может быть больше, чем часть, которую данный узел может кэшировать локально (например, x i i ≥ x i j , ∀ i , j , j ≠ i ). Во-вторых, сумма элементов в каждом столбце не может быть меньше, чем приблизительно единица, так как каждый узел CONA может иметь возможность получать полную копию объекта ( ∑ j ∈ I x i j ≥ 1 ). В соответствии с этим решением, подсистема CC может иметь возможность вычислять план по разделению каждого объекта и сохранению части объекта в каждом узле CONA.

Таблица 3 показывает решение, которое может быть получено с помощью решения формулировки задачи TECC для сети 100 в соответствии с ограничениями (22)-(28):

Таблица 3
i	1	2	3
xi 1 xi 2 …xi 3	.6	.2	.3
.2	.3	.7
	…
.1	.6	.7

Согласно приведенному выше решению три узла CONA 110, 120 и 130 могут кэшировать приблизительно 60 процентов, 20 процентов и 30 процентов, соответственно, объекта в классе 1. Сумма элементов в строке таблицы 3 может быть больше, чем приблизительно единица (например, ∑ i x i ≥ 1 ).

В одном из вариантов осуществления распределенный алгоритм может быть получен из декомпозиции приведенных выше задач оптимизации. Например, формулировку задачи TECC в соответствии с ограничениями (22)-(28) можно разделить на подзадачу TE сети и подзадачу CC сети. Когда решают подзадачу TE, можно вычислять стоимость p_e TE сети для множества линий связи. Стоимость p_e TE может быть стоимостью маршрутизации текущего трафика по линии связи e. Вычисленная стоимость TE может объединяться по маршруту в сети, например, по последовательности линий связи. Подзадача CC может быть решена средствами локального кэширования (например, узлами CONA), получая вычисленную стоимость TE и вычисляя оптимальное значение x_i ^k для каждого объекта, которое указывает, какую часть объекта каждый кэш может локально хранить. Индикаторная переменная x_i ^k может быть вычислена в соответствии со стоимостью TE.

Фиг. 2 показывает вариант осуществления схемы 200 распределенного TE и CC. Схема 200 распределенного TE и CC может воплощаться в сети с возможностью CONA, например, в сетевой архитектуре 100, изображенной на Фиг. 1. Схема 200 распределенного TE и CC может решать задачу TECC, решая подзадачу TE и затем подзадачу CC сети. Сеть может содержать узлы 210 и 220 CONA и другие узлы 225 (например, узлы, не являющиеся узлами CONA), которые включают в себя узлы 230, 240 и 250. Узлы 210-250 могут быть сконфигурированы по существу аналогично соответствующим узлам в сетевой архитектуре 100. Узлы 210-250 могут обрабатывать сетевой трафик на физическом уровне (и/или на любом другом уровне модели взаимодействия открытых систем (OSI)), и узлы 210 и 220 могут также быть узлами CONA, которые содержат средства локального кэширования, которые поддерживают CC.

Узлы 210-250 могут быть расположены так, как показано на Фиг. 2, причем узлы 225 могут располагаться в тракте между узлами 210 и 220 CONA. Также, узлы 230, 240 и 250 могут быть транзитными узлами, которые перемещают трафик, который включает в себя объекты контента, между узлами 210 и 220. С помощью решения подзадачи TE, стоимость каждой линии связи, например, p_e1(t) между узлами 230 и 240 и p_e2(t) между узлами 240 и 250, может вычисляться, например, в соответствии с количеством или объемом трафика по линиям связи. Линии связи обозначены пунктирными линиями на Фиг. 2. Вычисленную стоимость линии связи можно затем передавать к узлам 210 и/или 220 CONA (как обозначено сплошными линиями со стрелками на Фиг. 2). Полная стоимость линии связи t_k (t) для объединенных линий связи может вычисляться с помощью средства TE, которое может соответствовать одному или большему количеству узлов или серверов в сети, и передаваться к узлам 210 и/или 220 CONA, или может вычисляться узлами 210 и/или 220 в соответствии с переданной стоимостью линии связи, например, p_e1(t) и p_e2(t). Узлы 210 и/или 220 могут затем использовать стоимость линии связи для решения подзадачи CC и таким образом для вычисления локальной политики кэширования, например, локальной политики размещения копии или частей объекта, и они могут определять, как эти политики воплощают.

Фиг. 3 показывает вариант осуществления другой сетевой архитектуры 300, которая может иметь иерархическую структуру. Сетевая архитектура 300 может содержать множество узлов 310-350, которые могут быть соединены друг с другом в иерархической модели сети, например, в древовидной топологии. Соответственно, узлы могут быть классифицированы или организованы в различных иерархиях или уровнях, причем количество узлов на более низких иерархиях может быть больше количества узлов на более высоких иерархиях. Таким образом средняя пропускная способность на один узел на нижних иерархиях может быть меньше по сравнению с верхними иерархиями. Дополнительно, узлы на том же самом уровне могут не осуществлять связь друг с другом, но могут осуществлять связь с другими узлами на более высоких или более низких иерархиях. Например, узел 310 может быть расположен на первом уровне и может осуществлять связь с узлами 320 и 330 на более низком втором уровне, которые могут не осуществлять связь друг с другом непосредственно. Узел 320 может осуществлять связь с узлами 340 на более низком третьем уровне, которые могут не осуществлять связь друг с другом непосредственно. Точно так же узел 330 может осуществлять связь с узлами 350 на третьем уровне, которые также могут не осуществлять связь друг с другом непосредственно.

Сетевая архитектура 300 может быть особым случаем сетевой архитектуры 100, и узлы 310-350 могут быть сконфигурированы по существу аналогично соответствующим узлам 110-150. Например, узлы 310, 320 и 330 могут быть узлами CONA, а узлы 340 и 350 могут быть узлами, которые не являются узлами CONA. Таким образом, узлы 310, 320 и 330 могут кэшировать объекты контента в соответствии с любой из приведенных выше задач TECC. В одном из вариантов осуществления сетевая архитектура 300 может соответствовать сети доступа, где DSLAM, широкополосный сервер удаленного доступа (BRAS) и/или маршрутизаторы магистрали могут формировать иерархическую структуру с множеством уровней (например, с тремя уровнями). Например, узел 310 может содержать маршрутизатор магистрали, каждый из узлов 320 и 330 может содержать BRAS, и узлы 340 и 350 могут содержать множество DSLAM.

Для решения задачи TECC в сетевой архитектуре 300 различная стоимость линии связи (например, стоимость TE) может быть назначена линиям связи в различных иерархиях, например, ручным способом с помощью оператора. Например, если обычно DSLAM в относительно небольшой географической области (например, в микрорайоне, в районе с одним почтовым индексом, в городе или на другой территории, например, площадью приблизительно 5, приблизительно 10, приблизительно 20 или приблизительно 50 квадратных километров) подключены через коммутаторы Ethernet, то стоимость линий связи, которые подключают DSLAM, может быть по существу ниже, чем стоимость линий связи, которые подключают другие узлы BRAS. Стоимость можно предварительно вычислять, корректировать вручную заранее или оперативно (например, в режиме реального времени) или вычислять с помощью алгоритма по запросу.

Фиг. 4 - схематическое представление варианта осуществления средства 400 кэширования. Средство кэширования может быть расположено в узле CONA и может быть сконфигурировано для управления CC. Также, средство 400 кэширования может воплощать распределенный алгоритм CC (например, для решения подзадачи CC), генерировать политики CC, обновлять контент кэша согласно политикам CC, или их комбинации. Средство 400 кэширования может содержать средство 410 политики кэширования, компонент 420 алгоритма замещения, компонент 430 передачи данных между кэшами, компонент 440 получения статистической информации и средство 450 сохранения. Компоненты средства 400 кэширования могут быть расположены, как показано на Фиг. 4, и могут воплощаться, используя аппаратные средства, программное обеспечение или и то, и другое.

Средство 410 политики кэширования может содержать компонент 412 политики сети, компонент 414 глобальной политики кэширования и компонент 416 локальный политики кэширования. Компонент 412 политики сети может быть сконфигурирован для получения информации политики сети, например, информации обратной связи TE в соответствии со стоимостью TE линии связи, например, p_e. Когда рассматривают другие эксплуатационные требования, стоимость линии связи может определяться в контексте таких требований. Компонент 414 глобальной политики кэширования может быть сконфигурирован для изменения набора параметров, относящихся к перемещаемым частям объекта, например, x_j ^k, и соответствующих вероятностей, например, q_j ^k, с помощью другого средства или компонента кэширования (в других узлах CONA). Компонент 414 глобальной политики кэширования может осуществлять распределенный алгоритм для вычисления политики кэширования. Политика кэширования может содержать оптимальную стратегию размещения копии, например, x_i ^k, которая может быть входной информацией для компонента 416 локальной политики кэширования. Компонент 416 локальной политики кэширования может быть сконфигурирован для определения, какую часть каждого объекта следует локально кэши