Internet следующего поколения: не надежен на любой скорости?

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

Пользователям критически важных Internet-приложений потребуется функциональность, которая вряд ли будет сама по себе реализована в Internet следующего поколения (Next-Generation Internet — NGI). Традиционно критически важные Internet-приложения физически или логически изолируются в попытке оправдать предположения, в которых каждое приложение рассматривается как независимое. При переносе подобных приложений в разделяемую сетевую инфраструктуру изоляция утрачивается, ставя под угрозу их безопасность. В силу этого срочно необходимы средства обеспечения и контроля защиты для приложений NGI [1], для чего нужно найти способ изолировать приложения друг от друга в совместно используемой среде.

Разработчики приложений полагаются на те или иные методы изоляции, чтобы исключить непредвиденное вмешательство. Интерпретация слова «вмешательство», однако, зависит от приложения. Например, некоторые критически важные приложения требуют только защиты от вторжений злоумышленников, что корректным образом обеспечивают виртуальные частные сети (virtual private network — VPN). Такие архитектуры легко перенести и в NGI. Но в Сети не существует столь же простого решения для обеспечения «невмешательства» иного рода, например, отсутствие непредвиденных потерь полосы пропускания или возникновения задержек в виртуальной частной сети. Решение этой задачи позволило бы обеспечить гарантированный уровень обслуживания даже при возникновении сбоя.

Я предлагаю новый механизм для изоляции сетевых приложений, который я назвал виртуальной сетью с перекрытиями (virtual overlay network — VON). VON позволяет обеспечить надежность и безопасность, необходимые в критически важных приложениях, однако такое решение чрезвычайно дорого реализовать в рамках современных технологий. Расширение функциональности современных маршрутизаторов в сочетании с хорошо продуманными механизмами групповых коммуникаций позволят реализовать концепцию VON с разумными затратами и хорошей масштабируемостью.

Cети с перекрытиями и виртуальные сети с перекрытиями

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

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

Как показано на рисунке 1, сеть с перекрытиями будет характеризоваться следующими атрибутами:

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

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

Internet следующего поколения

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

Обеспечение более высокой производительности

Безусловно, NGI будет быстрее. Аналитики предполагают, что распространение широкополосных технологий и оптоволоконных кабелей позволит увеличить производительность Internet в 10 - 100 раз. Однако сама по себе производительность ничего не дает для решения задачи изоляции от нежелательного вмешательства. В частности, современный Internet намного быстрее Internet, существовавшего лет десять назад, в то время как проблемы вмешательства стали намного серьезнее. В популярной литературе, как правило, скорость неразрывно связывают с безопасностью, но, хотя скорость зачастую является необходимым условием для гарантий безопасности, она редко оказывается условием достаточным.

Увеличение уровня защиты

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

В работе, выполненной нашей исследовательской группой в Корнелле совместно с группой Transis из Еврейского университета в Иерусалиме, мы изучили расширение VPN на основе идеи виртуальных сетей с перекрытиями, сосредоточившись исключительно на вопросах защиты [2]. Наше решение, получившее название динамической виртуальной частной сети (Dynamic Virtual Private Network — DVPN) позволяет одной и той же машине одновременно входить в состав нескольких виртуальных частных сетей и обеспечивает отказоустойчивость. Мы также предложили протоколы DVPN для быстрого изменения ключей защиты при изменении набора участвующих компьютеров или приложений.

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

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

Средства изоляции

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

Известно много подходов к обеспечению качества обслуживания. Среди самых заметных - RSVP, RED, RIO и целое семейство решений, известных под названием Diffserv [4]. Все эти подходы во главу угла ставят гарантии, необходимые для телефонии и ориентированные на связь, осуществляемую по одноранговым соединениям. Разработка решений, рассчитанных на коммуникации многие-ко-многим, движется довольно медленно.

Решения, касающиеся поддержки качества обслуживания, можно разделить на две категории. Первая из них, примером которой является RSVP, резервирует ресурсы вдоль маршрута от источника к передатчику на короткие периоды времени. Вторая категория предусматривает создание пакетов в тот момент, когда они попадают в сеть. Этот подход требует, чтобы резервирование ресурсов осуществлялось службой, которая контролирует общие обязательства и сетевую маршрутизацию, принимая новые запросы, если маршрутизаторы могут их выполнить. Входящие пакеты помечаются как «профильные» («in profile») и «непрофильные» («out of profile»), и маршрутизаторы преимущественно «отбраковывают» последние, когда возникает переполнение. Дэвид Кларк и Джон Врославски [4] показали, что эта методика обеспечивает превосходные статистические гарантии, в то же время позволяет избежать полноценного решения дорогостоящей задачи классификации трафика в сети. А именно, при использовании RSVP или аналогичных схем, если существует n конечных точек в сети, типичный маршрутизатор в общем случае должен управлять O(n²) соединениями. Анализ, необходимый для классификации каждого пакета, проходящего через маршрутизатор (чтобы определить его резервирование), становится очень дорогим, возможно даже чересчур, и использование ресурсов может оказаться неэффективным. Протоколы Diffserv, предлагающие только статистические гарантии, обходится без такого дорогостоящего анализа. Маршрутизатор просматривает всего один бит заголовка.

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

Вполне вероятно, что резкое увеличение нагрузки, связанной с конкретной парой конечных точек (источник, пересылающий информацию некоторому адресату) может достичь предела производительности сети с перекрытиями. Таким образом, в нашем примере, надстраиваемая сеть должна гарантировать совокупную полосу пропускания 10 Мбит/с, но при этом иметь возможность предоставить пиковую полосу пропускания любой паре пользователей, которые оказались в состоянии генерировать полную нагрузку, когда все остальные конечные точки сети простаивают. Протокол резервирования ресурсов в зависимости от соединения может, таким образом, быть вынужден резервировать O(100² * 10) Мбит/с или 100 Гбит/с емкости центрального маршрутизатора. Действительно, такая реализация резервирования ресурсов впрямую может оказаться неудовлетворительной.

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

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

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

Альтернативы, поддерживающие VON

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

Использование разбиения

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

Пример виртуального маршрутизатора. К примеру, если Global Domination Networks отдаст в аренду Gotham Network Solutions половину емкости маршрутизатора, тогда каждый пакет GNS будет помечаться одним и тем же идентификатором потока, а маршрутизаторы GNS на сетевых маршрутах, оговоренных в контракте, будут отдавать половину своих ресурсов для GNS. В конечном итоге резервирование создает виртуальный маршрутизатор, выделенный для GNS. Мы можем даже представить сценарий, в котором пакеты GNS получают отказ от обслуживания из-за переполнения, хотя части тех же маршрутизаторов, принадлежащие GDN, простаивают.

Может возникнуть впечатление, что если у GDN возникает избыток доступных ресурсов, то она должна предложить их GNS. По здравому размышлению, однако, становится ясно, что решение будет корректным только в том случае, если при достижении уровня, оговоренного в контракте, GNS будет отказываться от обслуживания новых пакетов. Проблема в том, что такие протоколы, как Transmission Control Protocol, разработаны так, что они приостанавливают обработку «лишних» пакетов в том случае, когда возникает переполнение.

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

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

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

Реализация нескольких сетей с перекрытиями. Для начала представьте, что мы расширили этот существующий механизм до такого, который может поддерживать тысячи, а то и десятки тысяч потоков, но в остальном ведет себя точно также. Gotham Hospital в таком случае может приобрести несколько сетей с перекрытиями у GNS, которая резервируют ресурсы для сетей с перекрытиями на маршрутизаторах, связанных с маршрутизаторами, установленными между конечными точками сети госпиталя Gotham Hospital. В общем, каждая надстраиваемая сеть будет обслуживать некое большое число конечных точек. К примеру, госпитальная система мониторинга, возможно, будет «продолжена» в дома некоторых амбулаторных больных и может включать в себя несколько сотен мониторинговых устройств, которые совместно используют одну сеть с перекрытиями.

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

В этом примере есть два важных момента. Во-первых, каждая сеть с перекрытиями гарантирует изоляцию приложений, взаимодействующих в различных потоках. Эта фундаментальная особенность - ключ к созданию свойств более высокого уровня. А, во-вторых, поскольку каждая сеть с перекрытиями рассматривает поток как объединение, маршрутизаторы сталкиваются с проблемами резервирования, которые растут линейно с увеличением числа сетей с перекрытиями. Госпиталю Gotham Hospital, в котором могут использоваться тысячи компьютеров, потребуется множество VON. В отличие от проблемы O(n²), теперь есть лишь линейная зависимость от числа «предприятий», которые используют сеть, что на порядок меньше числа конечных точек.

Создание VON

Gotham Hospital хочет получить от сетей с перекрытиями не только выделенную полосу пропускания. Сеть мониторинга должна эмулировать стандарт IEEE-1073, как описано во врезке «Поучительный пример I: компьютерные системы для интенсивной терапии». Таким образом, эта сеть может удовлетворять требованиям обработки в реальном масштабе времени, которые отсутствуют в клинической сети, где предполагается эмуляция выделенного Ethernet. Сеть мониторинга может, вероятно, работать с ограниченным уровнем защиты, которая предусматривает использование подписей на пакетах и аутентификацию в момент подключения устройства к сети. С другой стороны, для клинической сети может потребоваться шифрование содержимого пакетов из соображений секретности, так что не удастся в полной мере воспользоваться более строгими гарантиями работы в реальном времени, а вдобавок это может снизить производительность сети. В общем, коммуникационные сети, которые предлагают свойства реального времени, работают медленнее, чем технологии, на которых они реализованы.

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

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

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

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

К примеру, рассмотрим протокол TCP. В традиционной сети мы, по сути, не можем утверждать, что соединение TCP надежно. Такое соединение потенциально может быть прервано в случае нарушения инфраструктуры, даже если ни в одной из конечных точек не возник сбой. В случае соединения TCP в пределах VON идентичный протокол может предложить более надежные гарантии, например того, что не работает не более одного сетевого канала или маршрутизатора, и соединение TCP никогда не будет прервано до тех пор, пока сбой не возник ни на одной из конечных точек, которые оно связывает. Эти специфические гарантии могут потребовать определенной избыточности в сети с перекрытиями, но мы можем представить все виды гарантий, формулируемых в терминах низкого уровня, преобразуя их свойства более высоких уровней, «видимые» через TCP и другие протоколы.

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

Этот метод создания распределенных протоколов за последние десять лет стал весьма популярным. Он был представлен как «потоковая» архитектура STREAMS, получившая распространение в Unix-системах, а затем обобщен в x-Kernel [5] и адаптирован к групповым приложениям в работе, которую мои коллеги и я проделали при создании систем Horus [6] и Ensemble [7]. Последняя работа показывает, как использовать формальные методы для определения, оптимизации и подтверждения свойств систем, структурированных подобным образом [8].

Рис. 1. Две виртуальные сети «наслаиваются» на одну физическую сеть Перекрытие обеспечивает изоляцию, скрывает физическую сеть и может обеспечить такие гарантии, как минимальная полоса пропускания. Овалами обозначены компьютеры; затененная часть рисунка - это «физический» Internet. С помощью предлагаемой технологии части сети изолируются от остального Internet.

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

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

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

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

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

Список примитивов для коммуникаций группового типа иллюстрирует лишь некоторые возможности в рамках спектра потенциальных механизмов, каждый из которых подходит для конкретного типа VON. Среди других возможностей - поддержка смены разбиения или мобильность, специализированные гарантии реального времени, другие виды защищенных архитектур, специализированные протоколы для передачи видео или другой мультимедиа-информации, инфраструктуры, которые интегрируют управление VON в механизмы уровня приложений, такие как автоматический перезапуск модулей и так далее. Во врезке «Поучительный пример II: интегрированное модульное авиационное оборудование в Boeing 777 SafeBus» описывает одно из возможных применений VON.

Суть моего предложения состоит в успешном усилении основных свойств за счет наслаивания программного обеспечения поверх базовых VON и, в конечном итоге, поверх базовой сети с перекрытиями при строгой изоляции и гарантиях резервирования ресурсов. Мы могли бы использовать те же виды протоколов и в Internet, но в Internet отсутствуют какие-либо гарантии. Такое решение может оказаться успешным, но, скорее всего, мы не сможем добиться желаемого результата, потому что многие свойства реализуются именно за счет свойств базовой сети с перекрытиями и изоляции надстраиваемой сети от внешнего вмешательства. Однако, наделив сеть с перекрытиями даже простейшими изоляционными свойствами, мы можем найти способы усилить их. В общем, мы должны представлять себе суть компромисса, в частности, что придется согласиться на дополнительные коммуникации для того чтобы добиться более высокой надежности.

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

Пока остается множество вопросов относительно сетей VON; непонятно даже, насколько они решаемы в принципе. Связанные с ними работы были проведены в сообществе, занимающемся «виртуальными сетями» [9, 10], а также представлено множество исследований, посвященных управлению сетями ATM, предлагающих гарантии качества обслуживания.

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

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

Я благодарен Денни Долеву, Фарнаму Джананьяну, Ксаомингу Лью, Озаду Родеху, Фреду Шнайдеру, Крису Стандишу, Роберту ван Ренесси и Питеру Вагнеру за их поддержку и предложения. Эта работа частично проводилась в рамках грантов DARPA/ ONR N00014-96-1014, DARPA/RADC F30602-99-1-0532 и NSF EIA 97-03470. В данной статье я выражал только свои взгляды, мнения и выводы и они могут не отражать мнение организаций, финансировавших эту работу.

Об авторе

Кеннет Бирман - профессор факультета информатики Корнеллского университета. К области его научных интересов относятся отказоустойчивость, надежность и безопасность распределенных компьютерных систем. С ним можно связаться по электронной почте по адресу: ken@cs.cornell.edu.

Литература

[1] R. Marsh, ed., Critical Foundations: Protecting America?s Infrastructure: The Report of the Presidential Commission on Critical Infrastructure Protection, Government Printing Office, Washington, D.C., 1997

[2] O. Rodeh et al., Dynamic Virtual Private Networks, Tech. Report TR-98-1695, Dept. of Computer Science, Cornell University, Ithaca, N.Y., 1998

[3] F. B. Schneider, ed., Trust in Cyberspace, National Academy of Sciences Press, Washington, D.C., 1998

[4] D. Clark and J. Wroclawski, An Approach to Service Allocation in the Internet, Internet Engineering Task Force Draft Report; http://diffserv.les.mit.edu/Drafts/draft-clark-diff-svc-alloc-00.tst, July 1997

[5] L. Peterson et al., «RPC in the X-Kernel: Evaluating New Design Techniques,» Proc. 12th Symp. Operating System Principles (SOSP), ACM Press, New York, 1989, pp. 91-101

[6] R. Renesse, K.P. Birman, and S. Maffeis, «Horus: A Flexible Group Communication System,» Comm. ACM, Apr. 1996, pp. 76-83

[7] M. Hayden, The Ensemble System, doctoral dissertation, Dept. of Computer Science, Cornell University, Ithaca, N.Y., 1998

[8] X. Liu et al., «Building Reliable, High-Performance Communication Systems from Components,» Proc. 17th Symp. Operating System Principles (SOSP), ACM Press, New York, 1999, pp. 80-92

[9] J.P. Redlich, M. Suzuki, and S. Weinstein, «Implementing Virtual Networks on the Internet,» 2nd IEEE Conf. Open Architectures and Network Programming (OPENARCH99), IEEE CS Press, Los Alamitos, Calif., 1999, pp. 71-83

[10] A. Campbell et al., «The Genesis Kernel: A Virtual Network Operating System for Spawning Network Architectures,» 2nd IEEE Conf. Open Architectures and Network Programming (OPENARCH99), IEEE CS Press, Los Alamitos, Calif., 1999, pp. 22-35

Поучительный пример I: компьютерные системы в интенсивной терапии

Поучительный пример II: интегрированное модульное авиационное оборудование в Boeing 777