Network Working Group                                         B. Gleeson
Request for Comments: 2764                                        A. Lin
Category: Informational                                  Nortel Networks
                                                             J. Heinanen
                                                           Telia Finland
                                                             G. Armitage
                                                                A. Malis
                                                     Lucent Technologies
                                                           February 2000

PDF

Основа для построения частных виртуальных сетей на базе IP

A Framework for IP Based Virtual Private Networks

Статус документа

Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов Internet и может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (2000). All Rights Reserved.

Примечание IESG

Этот документ не является результатом рабочей группы IETF. В настоящее время IETF не прилагает усилий по стандартизации конкретных моделей VPN.

Аннотация

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

1.0 Введение

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

Развертывание виртуальных частных сетей через магистрали IP вызывает значительный интерес. Однако повсеместное распространение VPN затрудняется нехваткой интероперабельных реализаций, которая, в свою очередь, обусловлена отсутствием общепринятых определений и трактовок применения VPN, а также путаницей, обусловленной применением термина VPN для описания самых разных решений. В контексте этого документа аббревиатура VPN трактуется, как «эмуляция частной распределенной сети (WAN²) с использованием средств IP» (включая сеть Internet и частные сети IP). По причине существования множества типов VPN, а также разных типов WAN, в трактовках VPN зачастую возникает путаница.

В этом документе VPN моделируется, как объект связности (connectivity object). Хосты могут подключаться к VPN, а сами VPN могут соединяться между собой так же, как это происходит при подключении к физическим сетям и организации соединений между физическими сетями (например, через мосты или маршрутизаторы). Многие аспекты сетей такие, как адресация, механизмы пересылки, обнаружение и анонсирование доступности, качество обслуживания (QoS), безопасность и межсетевое экранирование имеют общие решения как для физических, так и для виртуальных сетей, а многие вопросы, возникающие при рассмотрении VPN, имеют прямые аналогии с вопросами реализации физических сетей. Введение VPN не требует заново изобретать сети или создавать новые парадигмы, у которых бы не было прямых аналогий с существующими физическими сетями. Зачастую достаточно просто рассмотреть решение того или иного вопроса в физической сетевой среде и применить те же принципы в среде, содержащей как физические, так и виртуальные сети, для разработки нужных расширений или требуемых улучшений. Очевидно, что наличие общих для физических и виртуальных сетей механизмов упрощает внедрение VPN в существующих сетях, а также снижает издержки на разработку стандартов и продукции, поскольку позволяет воспользоваться имеющимися решениями.

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

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

Отметим, что в этом документе рассматриваются лишь реализации VPN через магистрали IP, будь то частные сети IP или сеть Internet. Описанные здесь модели и механизмы применимы как для IPV4, так и для IPV6. В документе осознанно не рассматриваются VPN на базе естественного отображения на коммутируемые магистрали — например, VPN на основе LANE⁴ [1] или MPOA⁵ [2], работающие через магистрали ATM. При построении магистралей IP на базе упомянутых протоколов путем соединения маршрутизаторов через коммутируемые магистрали, рассматриваемые VPN работают «поверх» сети IP и, следовательно, не используют напрямую естественные механизмы нижележащих магистралей. Естественные VPN привязаны к службам нижележащих уровней, тогда как VPN на базе IP могут расширяться по мере расширения сетей IP. Протоколы естественных VPN выходят за пределы компетенции IETF и разрабатываются такими организациями, как ATM Forum.

2.0 Приложения VPN и требования к реализациям

2.1 Общие требования к VPN

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

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

Сети WAN организуются обычно с использованием арендованных линий или выделенных каналов (например, Frame Relay или ATM) между разными сайтами. Оборудование CPE (коммутаторы или маршрутизаторы) на разных сайтах соединяют эти каналы в единую сеть, обеспечивающую связность сайтов. С учетом стоимости и сложности организации каналов, а также сложности настройки оборудования CPE такие сети обычно не являются полносвязными (fully meshed) и в них чаще используется тот или иной вариант иерархической топологии. Например, удаленные офисы могут непосредственно подключаться к ближайшему региональному офису, а те, в свою очередь, образуют полносвязную или многосвязную сеть.

Частные коммутируемые сети используются для подключения удаленных пользователей к сетям предприятий через телефонные сети PSTN или ISDN⁷. Обычно это реализуется за счет развертывания серверов удаленного доступа (NAS⁸) на одном или нескольких центральных сайтах. Пользователи организуют соединение с NAS по коммутируемым линиям, а сервер доступа взаимодействует с серверами аутентификации и учета (AAA⁹) для идентификации пользователей и предоставления каждому разрешенного набора услуг.

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

Использование Internet для частных коммуникаций не является чем-то новым и существует множество методов организации такой связи, включая контролируемую утечку маршрутов (controlled route leaking) [3]. Однако лишь недавно появились механизмы IP, удовлетворяющие требованиям по организации VPN, описанным здесь.

2.1.1 Передача пакетов «втемную»

Передаваемый через VPN трафик может не иметь отношения к трафику магистрали IP, поскольку трафик является мультипротокольным или по причине того, что IP-адреса в частной сети могут относиться к пространству IP, не связанному с IP-сетью, через которую передается трафик. В частности, IP-сеть может использовать адреса IP из приватных блоков [4].

2.1.2 Защита данных

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

Другая модель основана на передаче вопросов защиты сервис-провайдеру, предоставляющего услуги защищенных управляемых VPN. Это похоже на доверие к операторам при использовании общественных коммутируемых сетей Frame Relay или ATM, когда потребители услуг верят, что пакеты не могут быть направлены по некорректному пути, невозможно появление обманных пакетов, изменение пакетов в процессе передачи или анализ трафика без соответствующих полномочий.

Во второй модели функции межсетевого экранирования и безопасной доставки пакетов входят в зону ответственности сервис-провайдера. На провайдерской магистрали могут потребоваться различные уровни защиты в зависимости от сценария развертывания. Если трафик VPN передается через одну IP-магистраль (опорную сеть) провайдера, сильной защиты (типа IPSec [5]), может не потребоваться для туннелей между магистральными узлами. Если же трафик VPN проходит через множество сетей или оборудования, администрируемого независимо, может потребоваться реализация сильных механизмов защиты. Организация сильной защиты от провайдера может потребоваться и в тех случаях, когда заказчик считает сети IP (и особенно Internet) небезопасными. Независимо от корректности такого мнения оно означает одну из проблем, которые должны решаться в реализации VPN.

2.1.3 Гарантии QoS

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

2.1.4 Механизм туннелирования

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

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

2.2 VPN на базе сетей и CPE

Большинство современных реализаций VPN основано на оборудовании CPE. Возможности поддержки VPN встраиваются во множество устройств CPE, начиная от межсетевых экранов и заканчивая граничными маршрутизаторами WAN и специализированными шлюзами VPN. Такое оборудование может быть куплено и развернуто самими потребителями или сервис-провайдерами в качестве услуг аутсорсинга (в этом случае обычно с удаленным управлением).

Имеется также значительный интерес к VPN на базе сетей (network based VPN), когда обслуживание VPN передается поставщику услуг Internet (ISP¹⁰), а сами VPN реализуются на базе сетевого оборудования провайдера, а не устройств CPE. В таких решениях заинтересованы как стремящиеся снизить расходы на поддержку заказчики, так ISP, ищущие новые источники доходов. Поддержка VPN в сети позволяет использовать специальные механизмы, которые могут обеспечивать значительное преимущество в цене и эффективности VPN за счет реализации на одном оборудовании с единой поддержкой VPN большого числа заказчиков.

Большинство рассматриваемых ниже механизмов применимы к VPN на основе CPE или сетей. Однако часть механизмов применима только во втором варианте, поскольку требует средств (например, дополнений к протоколам маршрутизации), доступных ISP, которые вряд ли будут доступны потребителями или реализованы даже на принадлежащих и поддерживаемых ISP устройствах CPE по причине необходимости совместного управления работой CPE со стороны ISP и заказчика. Применимые лишь для VPN на базе сетей решения отмечены в документе явно.

2.3 VPN и Extranet

Термин «экстранет» (extranet) обычно используется для обозначений систем, где две или более компаний предоставляют друг другу ограниченный доступ к своим корпоративным ресурсам через сеть. Например, производственная компания может организовать extranet для своих поставщиков, чтобы обеспечить возможность запросов к базам данных для получения сведений о ценах и доступности компонент, а также отслеживания своих заказов. Другим примером может служить разработка программ — компания A открывает группе разработчиков из компании B доступ к исходным кодам своей операционной системы, а компания B разрешает специалистам компании A доступ к своим программам защиты. Отметим, что правила доступа могут быть неограниченно сложными. Например, компания B может иметь внутренние ограничения на доступ к своим программам защиты для пользователей из отдельных регионов планеты в соответствии с экспортными ограничениями.

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

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

Эта модель VPN позволяет отделить политику от нижележащего уровня, используемого для транспортировки пакетов. Например, маршрутизатор может направлять голосовой трафик в ATM VCC¹¹ для обеспечения гарантий QoS, нелокальный корпоративный трафик — в защищенные туннели, а весь остальной трафик — в канал подключения к сети Internet. В прошлом в качестве защищенных туннелей могли применяться виртуальные канала Frame Relay, а сейчас ими могут служить защищенные туннели IP или пути MPLS (LSP¹²)

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

3.0 Туннелирование VPN

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

Туннель IP, соединяющий две оконечные точки VPN, служит базой для построения множества разных служб VPN. Туннель IP работает, как наложение на магистральную сеть IP, и передаваемый через туннель трафик непрозрачен для нижележащей магистрали IP. Магистральная сеть IP используется в качестве технологии канального уровня, а туннели образуют каналы «точка-точка».

Устройство VPN может завершать множество туннелей IP и пересылать пакеты между этими туннелями и другими сетевыми интерфейсами различными способами. При обсуждении различных типов VPN в последующих разделах документа основными различиями будут именно способы пересылки между интерфейсами (например, мост или маршрутизатор). Здесь имеется прямая аналогия с характеристиками разных сетевых устройств. Двухпортовый повторитель просто пересылает пакеты между своими портами, не проверяя содержимого пакетов. Мост пересылает пакеты на основе информации уровня MAC¹³, содержащейся в пакете, а маршрутизатор при пересылке пакетов использует адреса уровня 3 из заголовков пакетов. Для каждого из этих вариантов имеется прямая аналогия в VPN, как будет показано ниже. Отметим, что туннель IP можно представлять себе, как отдельный тип канала, который может объединяться с другим каналом напрямую, через таблицу пересылки моста или таблицу маршрутизации IP в зависимости от типа VPN.

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

3.1 Требования к протоколам туннелирования для VPN

Существует множество механизмов туннелирования IP, включая IP/IP [6], туннели GRE¹⁴ [7], L2TP¹⁵ [8], IPSec [5], MPLS¹⁶ [9]. Отметим, что хотя некоторые из этих протоколов зачастую не рассматриваются в качестве туннельных, все они обеспечивают транспортировку кадров в полях данных пакетов (packet payload) через сети IP с пересылкой пакетов, не привязанной к адресной информации в инкапсулированных пакетах.

Отметим, однако, одно существенное различие между протоколами туннелирования IP, перечисленными выше, и MPLS. MPLS можно рассматривать, как конкретный канальный уровень для IP, поскольку конкретные механизмы MPLS применяются лишь в зоне действия сети MPLS, тогда как механизмы на базе IP расширяют пределы достижимости IP. По этой причине механизмы VPN, напрямую основанные на туннелировании MPLS, не могут по определению распространяться за пределы сети MPLS, тогда как другие механизмы могут делать это (например механизм LANE может применяться за пределами сетей ATM). Отметим, однако, что сеть MPLS может существовать на базе многих разных технологий канального уровня и, подобно сетям IP, область распространения такой сети не ограничена применением того или иного конкретного канального уровня. Имеется множество предложений по определению набора механизмов для обеспечения интероперабельности VPN (в частности, через сети MPLS [10] [11] [12] [13], [14], [15].

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

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

Возникают случаи, когда между парой конечных точек IP требуется организация множества туннелей VPN. Например, это может потребоваться в тех случаях, когда VPN организуется на уровне сети (network based), а каждая конечная точка поддерживает множество пользователей. Трафик разных пользователей проходит между парой физических устройств по разным туннелям. Для связывания пакетов с определенным туннелем требуется поле мультиплексирования. Совместное использование туннелей может также снижать задержки и объем работ при организации туннелей. Из числа имеющихся механизмов туннелирования IP механизмы мультиплексирования поддерживают L2TP (поля tunnel-id и session-id), MPLS (метка) и IPSec (поле SPI¹⁷). Строго говоря, в GRE поле мультиплексирования отсутствует. Однако поле key, предназначенное для аутентификации источника пакета, в некоторых случаях может служить в качестве поля мультиплексирования. IP/IP не имеет поля мультиплексирования.

IETF [16] и ATM Forum [17] стандартизовали единый формат уникальных в глобальном масштабе идентификаторов для VPN (VPN-ID). Идентификатор VPN-ID можно применять на уровне управления для привязки туннеля к VPN в момент организации туннеля, или на уровне данных для идентификации привязки пакетов к VPN. На уровне данных заголовок инкапсуляции VPN может использоваться MPLS, MPOA и другими механизмами туннелирования для агрегирования пакетов разных VPN в один туннель. В этом случае явная индикация VPN-ID включается в каждый пакет и используется в качестве поля мультиплексирования для данного туннеля. На уровне управления поле VPN-ID может включаться в любой сигнальный протокол организации туннелей для связывания туннеля (идентифицируемого например полем SPI) с VPN. В этом случае не будет необходимости включать VPN-ID в каждый пакет данных. Этот вопрос подробно рассматривается в параграфе 5.3.1.

3.1.2 Протокол сигнализации

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

Примером операции управления может служить использование базы SNMP MIB¹⁸ для настройки различных параметров туннеля (например, метки MPLS, адрес отправителя для туннеля IP/IP или GRE, идентификаторы туннеля и сессии L2TP, параметры защищенной связи IPSec).

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

При использовании в среде VPN сигнальному протоколу следует разрешать транспортировку VPN-ID, чтобы обеспечить возможность связывания туннеля с конкретной VPN. Следует также разрешать обмен и согласование атрибутов туннеля (например, применение восстановления порядка кадров или мультипротокольного транспорта). Отметим, что роль сигнального протокола состоит в согласовании атрибутов туннеля (например, пересылка пакетов через туннель на уровне 2 или 3), а не передаче информации о его использовании (это похоже на сигнализацию ATM Q.2931, который служит для организации логических подсетей Classical IP, а также эмулируемых ЛВС LANE).

Ряд протоколов туннелирования IP поддерживает сигнализацию, которую можно адаптировать для организации туннелей — L2TP (протокол L2TP), IPSec (протокол IKE¹⁹ [18]) и GRE (при использовании с туннелями mobile-ip [19]). Имеется также два сигнальных протокола MPLS, которые можно использовать для организации туннелей LSP. Один протокол использует расширение протокола MPLS LDP²⁰ [20], называемое CR-LDP²¹ [21], а другой — расширение RSVP²² для туннелей LSP [22].

3.1.3 Защита данных

Протокол туннелирования VPN должен поддерживать механизмы, позволяющие пользователям установить тот или иной уровень защиты, включая аутентификацию и/или шифрование разного уровня. Ни один из рассматриваемых механизмов туннелирования, за исключением IPSec, не имеет встроенных механизмов защиты и все они скорее опираются на средства защиты в опорных сетях IP. В частности, MPLS работает на основе явных метод для путей с коммутацией по меткам, что обеспечивает предотвращение перенаправления пакетов. Другие механизмы туннелирования обеспечивают защиту на базе IPSec. Для VPN, реализованных через опорные сети, отличные от IP (например, MPOA, Frame Relay или виртуальные каналы ATM), защита данных неявно обеспечивается сетевой инфраструктурой канального уровня.

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

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

В настоящее время протокол IPSec ESP²³ [23] для организации SA, которые могут поддерживать шифрование и/или аутентификацию. Однако спецификация протокола исключает применение SA, где нет ни шифрования, ни аутентификации. В среде VPN такой вариант null/null может оказаться полезным, поскольку может оказаться достаточным поддержка других аспектов протокола (например, туннелирования и мультиплексирования). Эффективно вариант null/null может рассматриваться просто как некий уровень защиты данных.

3.1.4 Мультипротокольный транспорт

Во многих приложениях через VPN может передаваться «непрозрачный», мультипротокольный трафик. В таких случаях туннельный протокол также должен поддерживать мультипротокольный транспорт. Протокол L2TP разработан для передачи пакетов PPP²⁴ [24] и, таким образом, может использоваться для передачи мультипротокольного трафика, поскольку сам транспорт PPP является мультипротокольным. Для идентификации туннелируемого протокола используется GRE. Туннели IP/IP и IPSec не имеют идентификационного поля, поскольку предполагают инкапсуляцию трафика IP.

Возможно расширение стека протоколов IPSec для поддержки мультипротокольного транспорта. Это можно реализовать, например, за счет расширения сигнальной компоненты IPSec — протокола IKE — для индикации типа протокола в туннелируемом трафике или за счет передачи заголовка мультиплексирования (например, LLC/SNAP или GRE) в каждом туннелируемом пакете. Это решение похоже на используемый в сетях ATM подход, когда используется сигнализация для указания инкапсуляции, применяемой в VCC, а передаваемые в VCC пакеты могут использовать заголовок LLC/SNAP или помещаться непосредственно в поля данных AAL5 (этот вариант называется VC-мультиплексированием [25]).

3.1.5 Сохранение последовательности кадров

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

Можно расширить IPSec для поддержки использования поля порядкового номера в целях сохранения порядка доставки пакетов. Это можно сделать, например, за счет использования IKE для согласования упорядочения и выбора поведения конечных точек в части обработки этого поля.

3.1.6 Поддержание туннеля

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

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

Другой вариант не требует от протокола туннелирования поддержки функций мониторинга и использует тот или иной внешний (out-of-band) механизм обнаружения потери связи. Например, если протокол маршрутизации типа RIP²⁵ [26] или OSPF²⁶ [27] работает через туннельную сеть, отсутствие информации от соседа в течение определенного времени приведет к тому, что протокол сочтет туннельное соединение разорванным. Другим способом может служить регулярная передача пакетов ICMP (ping) по адресу партнера. Это обычно обеспечивает достаточно эффективный способ проверки работы туннеля, поскольку он организован через ту же сеть IP.

При динамической организации туннелей нужно различать требуемую статическую и динамическую информацию. До того, как туннель может быть организован, узлу нужно получить некоторую статическую информацию, такую, как идентификация удаленной точки и атрибуты туннеля. Обычно такая информация задается в процессе настройки конфигурации. В результате сигнального обмена при организации туннеля на каждой конечной точке создается некое динамическое состояние (например, значение поля мультиплексирования или используемые ключи). Например, при использовании IPSec организация защищенной связи (SA²⁷) будет сопровождаться появлением ключей, используемых во время существования данной SA.

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

3.1.7 Большие MTU

С туннелями IP связаны значения MTU²⁸, как для обычных каналов. Можно предположить, что это значение MTU превысит MTU на одном или нескольких интервалах пути между конечными точками туннеля. В таких случаях для туннеля потребуется та или иная форма фрагментации кадров.

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

Другим решением является поддержка функций фрагментации и сборки фрагментов на уровне протокола туннелирования (возможно с использованием порядковых номеров и маркеров последнего фрагмента²⁹). Это позволит избежать фрагментации IP в самом туннеле. Однако существующие протоколы туннелирования не поддерживают такого механизма.

3.1.8 Минимизация туннельных издержек

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

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

3.1.9 Управление потоком и контроль перегрузки

При разработке протокола L2TP были созданы процедуры для контроля потоков и перегрузок. Это было вызвано, прежде всего, необходимостью обеспечить производительность при работе в сетях с большими потерями с использованием компрессии PPP, которая, в отличие от IPComp³⁰ [28], связана с состояниями пакетов. Другим мотивом послужила необходимость использования устройств с малым размером буферов, которыми часто завершаются низкоскоростные коммутируемые линии. Однако механизмы контроля потоколов и перегрузок, определенные в финальной спецификации L2TP, используются только для управления каналами, а не трафиком данных.

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

Отметим также работу группы IETF PILC³¹, исследующей влияние свойств каналов на производительность работы протоколов Internet через такие каналы.

3.1.10 Управление трафиком и QoS

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

Полное рассмотрение вопросов QoS для VPN выходит за рамки этого документа, за счет моделирования туннелей VPN, как специального типа канального уровня, многие из существующих механизмов обеспечения QoS для физических соединений могут быть применены для VPN. Например, на узле VPN механизмы правил, маркировки, очередей и планирования могут применяться к специфическому трафику VPN, как к обычному (не VPN) трафику. Применимы также методы, разработанные группами Diffserv, Intserv и TE³² в MPLS. Обсуждение вопросов QoS в VPN приведено в работе [29].

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

3.2 Рекомендации

IPSec требуется в тех случаях, когда нужно надежное шифрование или строгая аутентификация. Поддерживается также мультиплексирование и сигнализация (протокол IKE). Однако расширение стека протоколов IPSec на перечисленные ниже области обеспечит преимущества в плане улучшения поддержки требований туннелирования в средах VPN:

• транспортировка VPN-ID в процессе организации SA (3.1.2);

• опции пустого шифрования (null encryption) и пустой аутентификации (null authentication) (3.1.3);

• работа с множеством протоколов (3.1.4);

• упорядочение кадров (3.1.5).

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

4.0 Типы VPN — виртуальные выделенные линии

Простейшим вариантом VPN являются «виртуальные выделенные линии» (VLL³³). В этом случае заказчик получает соединение типа «точка-точка» между двумя устройствами CPE, как показано ниже. На канальном уровне для подключения устройств CPE к узлам ISP могут использоваться разные технологии (например, ATM VCC или каналы Frame Relay). Устройствами CPE могут служить маршрутизаторы, мосты или хосты.

Оба узла ISP подключены к сети IP и между ними организуется туннель IP. Каждый узел ISP настраивается на привязку оконечного канала к туннелю IP на уровне 2 (например, ATM VCC связывается с туннелем IP). Кадры передаются между двумя каналами. Например, данные AAL5³⁴) инкапсулируются в туннель IPSec. Содержимое полей данных AAL5 «непрозрачно» для узла ISP и не просматривается им.

            +--------+      -----------       +--------+
+---+       |Конечный|     (Магистраль )      |Конечный|      +---+
|CPE|-------|узел    |-----( IP        ) -----|узел    |------|CPE|
+---+ ATM   |ISP     |     (           )      |ISP     |  ATM +---+
      VCC   +--------+      -----------       +--------+  VCC
                    <--------- Туннель IP -------->

10.1.1.5                подсеть = 10.1.1.4/30              10.1.1.6
  Адресация, используемая потребителем (прозрачна для провайдера)

Рисунок 4.1 Пример VLL

С точки зрения потребителя услуги это выглядит, как обычный канал ATM VCC или Frame Relay, соединяющий между собой устройства CPE и потребитель может просто не думать о том, что часть канала фактически реализована через сеть IP. Это может оказаться полезным в тех случаях, когда провайдер, например, желает обеспечить связь между ЛВС через интерфейсы ATM, но не имеет собственной инфраструктуры ATM для непосредственного соединения сайтов заказчика.

Два канала, используемых для подключения устройств CPE к узлам ISP, могут быть организованы через разные среды, но в этом случае трафик не будет прозрачным для узлов ISP, как описано выше. Узлы ISP в такой ситуации должны поддерживать функции межсетевых устройств, соединяющих разнотипные среды (например, ATM и Frame Relay), а также выполнять функции преобразования LLC/SNAP в NLPID, отображения для разных вариантов протокола ARP или иные специфические операции, которые могут потребоваться для устройств CPE (например, обработка ячеек ATM OAM или обмен Frame Relay XID).

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

Отметим, что использование термина VLL в данном документе отличается от принятой в EF-PHB³⁵ [30], где VLL рассматривается, как соединение с малой и стабильной задержкой и гарантированной полосой пропускания, которое может быть организовано с использованием упомянутого PHB. Т. е., внимание фокусируется на характеристиках канала, которые по природе своей зависят от времени. В данном же документе для VLL не предполагается использование какого-либо конкретного механизма QoS, Diffserv или иного. Здесь принимаются во внимание прежде всего топологические характеристики (например, организация канала с туннелем IP в одном из сегментов). Для полной эмуляции канального уровня следует принимать во внимание как временные, так и топологические параметры.

5.0 Типы VPN — виртуальные маршрутизируемые сети (VPRN)

5.1 Характеристики VPRN

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

Отличительной чертой VPRN по сравнению с другими типами VPN является пересылка пакетов на сетевом уровне. VPRN включает многосвязную сеть туннелей IP между маршрутизаторами ISP и функции маршрутизации, требуемые для пересылки каждым узлом VPRN полученного трафика соответствующему сайту-получателю. К маршрутизаторам ISP подключаются маршрутизаторы CPE с использованием одного или нескольких оконечных (stub) каналов. На каждом маршрутизаторе ISP имеется специфическая для VPRN таблица пересылки. Трафик пересылается между маршрутизаторами ISP, а также между этими маршрутизаторами и сайтами заказчиков с использованием упомянутых таблиц пересылки, которые содержат информацию о доступности на сетевом уровне (в отличие от сетей VPLS³⁷, где таблицы пересылки содержат информацию о доступности на уровне MAC, как описано в разделе 7.0).

Пример VPRN показан на приведенном ниже рисунке, где три граничных маршрутизатора ISP соединены через полносвязную сеть туннелей IP и служат для связи между 4 маршрутизаторами CPE. Один из маршрутизаторов CPE имеет два соединения с ISP. В этом случае оба канала могут быть активны или может применяться, показанный на рисунке вариант «основной-резервный». Термином «обходной» канал на рисунке означено соединение между двумя пользовательскими сайтами, не использующее сеть ISP.

10.1.1.0/30 +--------+                       +--------+ 10.2.2.0/30
+---+       |Граничн.|     туннель IP        |Граничн.|       +---+
|CPE|-------|маршрут.|<--------------------->|маршрут.|-------|CPE|
+---+оконечн|ISP     |     10.9.9.4/30       |ISP     |оконечн+---+
     канал  +--------+                       +--------+канал    :
             |   ^  |                         |   ^             :
             |   |  |     ---------------     |   |             :
             |   |  +----(               )----+   |             :
             |   |       ( Магистраль IP )        |             :
             |   |       (               )        |             :
             |   |        ---------------         |             :
             |   |               |                |             :
             |   |туннель IP +--------+ туннель IP|             :
             |   |           |Граничн.|           |             :
             |   +---------->|маршрут.|<----------+             :
             |   10.9.9.8/30 |ISP     | 10.9.9.12/30            :
    резервный|               +--------+                обходной :
    канал    |                |      |                  канал   :
             | оконечн. канал |      | оконечн. канал           :
             |                |      |                          :
             |             +---+    +---+                       :
             +-------------|CPE|    |CPE|.......................:
             10.3.3.0/30   +---+    +---+      10.4.4.0/30

Рисунок 5.1 Пример VPRN

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

VPRN отличаются от сетей VPN, где сеть туннелей включает маршрутизаторы CPE, а сеть ISP обеспечивает также услуги канального уровня. Такие сети могут быть реализованы с использованием множества VLL между маршрутизаторами CPE (см. раздел 4.0), когда сеть ISP обеспечивает множество соединений «точка-точка» на канальном уровне или с помощью VPLS (см. раздел 7.0), где сеть ISP используется для эмуляции сегмента ЛВС с множественным доступом. Такие сценарии обеспечивают потребителям большую гибкость (например, между сайтами заказчика можно использовать любую маршрутизацию IGP и любые протоколы), но обычно дороже и сложнее в настройке. Таким образом, в зависимости от требований заказчика может оказаться более подходящим решение на основе VPRN или VPLS.

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

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

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

5.1.1 Топология

Топология VPRN может представлять собой полносвязную (full mesh) сеть туннелей между всеми узлами VPRN или использовать иной вариант соединений (например, подключение каждого удаленного офиса к ближайшему региональному узлу и многосвязная сеть соединений между региональными узлами). В сетях VPRN с использованием туннелей IP организация полносвязной сети соединений будет стоить существенно дешевле, нежели организация такой сети на физическом уровне (например, по арендуемым линиям) или использование метода туннелирования, требующего выделения ресурсов (например, Frame Relay DLCI) на устройствах, используемых для подключения к граничным маршрутизаторам. Полносвязная топология обеспечивает оптимальную маршрутизацию, когда трафик между парой сайтов передается напрямую без прохождения через транзитные узлы. Другим преимуществом полносвязной сети является отсутствие необходимости настройки топологии VPRN. Топология соединений между маршрутизаторами VPRN в данном случае просто задается неявно. Однако, если число граничных маршрутизаторов ISP в сети VPRN слишком велико, использование полносвязной топологии может стать неприемлемым по причине сложности масштабирования, связанных, например, с очень большим числом туннелей (n(n-1)/2 для n сайтов) или числом маршрутов к партнерам. Сетевая политика также может препятствовать организации полносвязной сети (например, администратор может принять решение о прохождении всего трафика через центральный сайт). Следует также принимать во внимание, что при возникновении ошибок в опорной сети IP часть туннелей может терять работоспособность (например, сайт A будет видеть сайт B, B будет видеть C, но для сайта A сайт C не будет доступен напрямую) в зависимости от политики маршрутизации.

Для основанных на сетях VPRN предполагается, что маршрутизатор CPE на каждом пользовательском сайте подключается к граничному маршрутизатору ISP через один или несколько каналов «точка-точка» (например, арендованные линии, соединения ATM или Frame Relay). Маршрутизаторы ISP отвечают за получение и распространение данных о доступности между собой. Маршрутизаторы CPE должны знать множество адресатов, доступных через каждый из каналов, хотя они могут просто пользоваться маршрутом по умолчанию.

Подключение абонентов может быть статическим (организуются на постоянной основе) или динамическим (организуется по запросу) на основе PPP, туннелей (см. параграф 6.3) или сигнализации ATM. Для динамических соединений требуется аутентификация подписчиков и определение ресурсов, которые могут им предоставляться (например, VPRN, к которым подписчик может подключаться). После подключения подписчика к VPRN (и выполнения дополнительных операций типа выделения динамических адресов IP) последующее использование механизмов и служб VPRN не будет зависеть от типа подключения абонента.

5.1.2 Адресация

Используемая в VPRN адресация может быть не связанной с адресами опорной сети IP, на основе которой организована эта VPRN. В частности, могут использоваться адреса IP из приватных блоков [4]. Через один набор физических устройств может быть организовано множество VPRN, причем их адресные пространства могут перекрываться.

5.1.3 Пересылка

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

Поскольку VPRN работает на межсетевом уровне, для пакетов IP, передаваемых через туннель, поле времени жизни (TTL³⁸) будет декрементироваться, как обычно, для предотвращения бесконечной циркуляции пакетов по сети в случае возникновения маршрутной петли в VPRN.

5.1.4 Множество VPRN через одно соединение

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

5.2 Работы, связанные с VPRN

Требования и механизмы VPRN обсуждались ранее во множестве разных документов. Одной из первых была работа [10], где было показано, что в сетях с поддержкой и без поддержки MPLS может быть реализована одинаковая функциональность VPN. Некоторые другие работы кратко рассмотрены ниже.

Существует два основных варианта механизмов обеспечения в VPRN функций распространения информации о принадлежности и доступности — наложение (overlay) и совмещение (piggybacking). Эти варианты подробно рассматриваются ниже в параграфах 5.3.2, 5.3.3 и 5.3.4. Пример модели с наложением описан в [14], где рассматривается обеспечение функциональности VPRN с помощью отдельного экземпляра протокола маршрутизации для каждой VPN с организацией таблицы маршрутизации и пересылки — такое решение называют виртуальной маршрутизацией. Каждый экземпляр маршрутизации VPN изолирован от маршрутизации остальных VPN, а также от маршрутизации опорной сети. Это позволяет использовать в сетях VPRN любые протоколы маршрутизации (например, OSPF, RIP2, IS-IS), независимо от маршрутизации в других VPRN и и опорной сети. Модель VPN, описанная в [12], также работает на основе наложения с использованием виртуальной маршрутизации. Этот документ специально ориентирован на обеспечение функциональности VPRN на основе опорных сетей MPLS и описывает, как можно автоматизировать распространение информации о принадлежности к VPRN через сеть MPLS путем обнаружения соседей VPN через базовую сеть туннелей MPLS. В работе [31] модель виртуальной маршрутизации расширена путем включения областей VPN и граничных маршрутизаторов VPN между такими областями. Области VPN могут определяться в соответствии с техническими (например, тип сетевой инфраструктуры ATM, MPLS, IP) или административными аспектами.

В работе [15] описано обеспечение функциональности VPN на основе модели совмещения в плане распространения информации о принадлежности и доступности, которая передается в пакетах протокола маршрутизации BGP4³⁹ [32]. VPN создаются с использованием правил BGP, которые служат для контроля взаимодействия между сайтами. В [13] также используется распространение информации по протоколу BGP и сведения о доступности из этого протокола служат для организации MPLS LSP (CR-LDP или расширенных RSVP). В отличие от других вариантов в данной модели для реализации функций VPN требуется участие маршрутизаторов CPE.

5.3 Базовые требования VPRN

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

1. Использование глобально уникальных идентификаторов VPN для обеспечения возможности указать конкретную VPN.

2. Определение принадлежности к VPRN. Граничный маршрутизатор должен определить оконечные соединения с каждой VPRN, а также набор маршрутизаторов данной VPRN.

3. Информация о доступности оконечных соединений. Граничный маршрутизатор должен определить адреса и префиксы, доступные через каждый оконечный канал.

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

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

5.3.1 Идентификатор VPN

IETF [16] и ATM Forum [17] стандартизовали единый формат уникальных в глобальном масштабе идентификаторов VPN — VPN-ID. Формат VPN-ID является единым, но семантика и применение различаются. Причина этого обусловлена желанием использовать один и тот же идентификатор для различных технологий и механизмов. Например, VPN-ID может включаться в базу MIB для идентификации VPN с целями управления. VPN-ID может использоваться на уровне управления, например, для привязки туннеля к VPN в момент организации этого туннеля. Все проходящие через туннель пакеты будут неявно связываться с данной VPN. Идентификатор VPN-ID может применяться в инкапсуляции на уровне данных, что позволяет явно различать пакеты каждой сети VPN. Если VPN реализуется с использованием разных технологий, (например, IP и ATM), для всех технологий может использоваться один идентификатор. Точно так же один идентификатор может применяться для VPN, организованных через множество административных доменов.

Большинство разработанных схем VPN (например, [11], [12], [13], [14]) требует использования VPN-ID в пакетах управления и/или данных для привязки каждого пакета к конкретной VPN. Хотя такое использование VPN-ID применяется широко, оно не является повсеместным. В работе [15] описана схема, где поле протокола не применяется для идентификации VPN описанным способом. В этой схеме VPN с точки зрения пользователя являются административными конструкциями на основе правил BGP. Имеется множество атрибутов, связанных с маршрутами VPN (идентификаторы маршрутов, VPN отправителя и получателя), которые применяются нижележащими протоколами для и эти же атрибуты используются механизмами BGP при создании VPN, но в этой схеме нет никакого аналога VPN-ID, используемого в данном документе.

Отметим также, что в [33] определена мультипротокольная инкапсуляция для использования с ATM AAL5 и стандартных VPN-ID.

5.3.2 Настройка и распространение конфигурационных данных VPN

Для организации VPRN или добавления новых пользовательских сайтов в существующую VPRN граничный маршрутизатор ISP должен определить, какие оконечные каналы связаны с какими VPRN. Для статических соединений (например, ATM VCC) эта информация должна указываться в конфигурации граничного маршрутизатора, поскольку он не может учесть такие привязки самостоятельно. Одним из решений являются базы SNMP MIB, позволяющие связать локальные оконечные каналы с VPN.

Для абонентов с динамическим подключением к сети (например, туннели PPP) можно организовать привязку оконечных соединений к VPRN, как часть процесса аутентификации пользователя, который применяется для таких динамических соединений. Например, VPRN, к которой привязывается пользователь, может определяться по доменному имени, использованному при аутентификации PPP. Если аутентификация пользователя завершилась успешно (например, с помощью сервера), новое динамическое соединение может быть привязано к нужной VPRN. Отметим, что статические конфигурационные данные по прежнему нужны (например, список уполномоченных пользователей для каждой VPRN), но эти конфигурационные данные могут храниться на внешнем сервере аутентификации, а не на граничном маршрутизаторе ISP. Независимо от того, является соединение статическим или динамическим, с ним может быть связан идентификатор VPN-ID, указывающий на конкретную VPRN.

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

5.3.2.1 Просмотр каталогов

Участники конкретной VPRN (т. е., граничные маршрутизаторы, поддерживающие оконечные каналы в VPRN, и множества оконечных каналов, привязанных к граничным маршрутизаторам VPRN) могут быть указаны в каталоге (directory), к которому граничные маршрутизаторы могут при старте обращаться с помощью того или иного механизма (например, LDAP⁴⁰ [34]).

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

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

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

5.3.2.2 Явная конфигурация

Можно определить VPRN MIB для централизованного управления системой с возможностью настройки каждого маршрутизатора, обеспечивающей идентификацию вовлеченных граничных маршрутизаторов и статических оконечных каналов, привязанных к VPRN. Этот механизм, подобно каталогам, поддерживает полносвязную и произвольную топологию. Другим механизмом централизованного управления может служить сервер управления и протокол COPS⁴¹ [35] для распространения информации о принадлежности к VPRN и правилах (например, атрибуты туннелей, используемые при организации туннелей, как описано в [36]).

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

5.3.2.3 Совмещение с протоколами маршрутизации

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

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

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

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

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

5.3.3 Информация о доступности оконечных каналов

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

5.3.3.1 Сценарии подключения оконечных каналов

5.3.3.1.1 Общее соединение для VPRN и Internet

Маршрутизатор CPE подключен одним каналом к граничному маршрутизатору ISP, который обеспечивает сервис VPRN и подключение к Internet.

Это простейший случай и маршрутизатору CPE нужен лишь используемый по умолчанию маршрут к граничному маршрутизатору ISP.

5.3.3.1.2 Отдельное соединение для VPRN

Маршрутизатор CPE соединяется одним каналом с граничным маршрутизатором ISP, который обеспечивает услуги VPRN без доступа в Internet.

Маршрутизатор CPE должен знать множество нелокальных адресатов VPRN, доступных через этот канал. Это может быть общий префикс или группа разрозненных префиксов. Эти данные должны быть включены в конфигурацию маршрутизатора CPE статически или определены им с помощью запущенного процесса IGP⁴³. Для простоты будем предполагать, что в качестве IGP используется протокол RIP, хотя это может быть и любой другой IGP. Краевой маршрутизатор ISP будет передавать этому экземпляру RIP маршруты VRPN, которые он узнал с помощью того или иного механизма определения доступности в рамках VPRN (см. параграф 5.3.4). Отметим, что экземпляр RIP на устройстве CPE и любой экземпляр протокола маршрутизации, служащий для определения доступности внутри VPRN (даже если это RIP), не связаны между собой и маршруты между ними распространяет граничный маршрутизатор ISP.

5.3.3.1.3 Многодомые подключения

Маршрутизатор CPE имеет множество подключений к сети ISP, которые обеспечивают соединение в VPRN.

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

5.3.3.1.4 Обходные каналы

Маршрутизатор CPE соединен с сетью ISP, обеспечивающей подключение к VPRN, и имеет также «обходной» канал к одному из сайтов организации.

В этом случае граничный маршрутизатор ISP будет анонсировать маршруты VPRN устройству CPE (как в случае 2). Однако в этом случае один и тот же адресат может быть доступен как через граничный маршрутизатор ISP, так и по обходному каналу. Если маршрутизаторы CPE соединены с обходным каналом и используют корпоративный IGP, обходной канал может оказаться более предпочтительным во всех ситуациях, поскольку он представляется внутренним, тогда как маршруты от граничного маршрутизатора ISP будут внешними по отношению к IGP. Для предотвращения возможных проблем (в предположении, что заказчик желает передавать трафик через сеть ISP) следует использовать отдельный экземпляр RIP между маршрутизаторами CPE на обоих концах обходного канала (так же, как протокол RIP используется на оконечном или резервном канале между маршрутизатором CPE и граничным маршрутизатором ISP. В этом случае обходной канал будет выглядеть, как внешний, и с помощью подбора «стоимости» пути маршрут через ISP можно сделать предпочтительным, используя обходной канал в случае отказа.

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

5.3.3.2 Экземпляр протокола маршрутизации

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

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

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

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

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

Отметим, что в тех случаях, когда тот или иной сайт заказчика входит одновременно в несколько VPRN (или хочет одновременно использовать VPRN и доступ в Internet), граничный маршрутизатор ISP должен иметь способ однозначного отображения адресных префиксов оконечного канала на конкретные VPRN. Простым решением является использование отдельного оконечного канала для каждой VPRN, однако можно подключать и множество VPRN через общий оконечный канал. Это можно сделать с помощью отображения (и соответствующей настройки граничного маршрутизатора ISP) на разные VPRN непересекающихся адресных префиксов или за счет маркировки маршрутных анонсов от CPE идентификаторами VPN. Например, при использовании MPLS для передачи данных о доступности оконечного соединения можно применять разные метки MPLS для непересекающихся адресных префиксов различных VPRN. В любом случае для решения этой задачи нужна та или иная административная процедура.

5.3.3.3 Настройка конфигурации

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

5.3.3.4 Администрируемые ISP адреса

Множество адресов, используемых каждым тупиковым сайтом может администрироваться и выделяться через граничный маршрутизатор VPRN и такое решение может быть приемлемо для небольших сайтов, которые зачастую состоят из одного хоста или одной подсети. Выделение адресов может выполняться с помощью протоколов типа PPP или DHCP [37], а граничный маршрутизатор может служить клиентом Radius, получающим IP-адреса для пользователей от сервера Radius, или служить транслятором DHCP, проверяя отклики DHCP, транслируемые сайту заказчика. В этом случае граничный маршрутизатор может самостоятельно построить таблицу доступности адресов через оконечный канал. Хотя упомянутые механизмы обычно используются для выделения адресов отдельным хостам, некоторые производители добавили расширения, позволяющие выделять префиксы, а устройства CPE могут выполнять функции серверов DHCP и выделять адреса для хостов на сайте заказчика.

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

5.3.3.5 Протокол распространения меток MPLS

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

5.3.4 Информация о доступности внутри VPN

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

Задача распространения информации о доступности адресов внутри VPN может быть решена множеством способом. Некоторые из этих решений описаны ниже.

5.3.4.1 Просмотр каталога

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

5.3.4.2 Явная настройка конфигурации

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

5.3.4.3 Локальные экземпляры маршрутизации внутри VPRN

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

Отметим, что этот протокол маршрутизации внутри VPRN не требуется связывать с IGP на сайтах заказчика или протоколами маршрутизации, используемыми ISP в опорной сети IP. В зависимости от размера и масштабов VPRN может использоваться простой протокол типа RIP или более изощренный протокол типа OSPF. Поскольку протокол маршрутизации внутри VPRN работает «поверх» опорной сети IP, он не заметен для всех промежуточных маршрутизаторов и граничных маршрутизаторов, не относящихся к VPRN. Это также предполагает, что такая информация будет непонятной (opaque) для этих маршрутизаторов, что в некоторых случаях может оказаться важным с точки зрения безопасности. Отметим также, что при использовании протокола маршрутизации через те же туннели, которые служат для передачи данных, для пакетов маршрутизации будет обеспечиваться такая же защита (например, шифрование и аутентификация источника).

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

5.3.4.4 Протокол доступности канала

Протокол доступности канала обеспечивает двум узлам, соединенным каналом «точка-точка» обмениваться данными о доступности. Для случая полносвязной топологии на каждом граничном маршрутизаторе может применяться протокол доступности канала (например, та или иная вариация MPLS CR-LDP) через туннели со всеми граничными маршрутизаторами VPRN. Этот протокол передает VPN-и информацию о доступности каждой VPRN, работающей через туннель между двумя граничными маршрутизаторами. Если информация о принадлежности к VPRN уже была передана граничному маршрутизатору, используемое в традиционных протоколах маршрутизации обнаружение соседей уже не требуется, поскольку соседи известны. Для организации надежных соединений с соседями может применяться транспорт TCP. Такая модель может снижать издержки, связанные с использованием отдельных экземпляров протокола маршрутизации для каждой VPRN, и может обеспечивать преимущества за счет применения общего туннеля для соединения множества граничных маршрутизаторов, поддерживающих разные VPRN.

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

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

5.3.4.5 Совмещение в протоколах маршрутизации опорных сетей IP

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

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

5.3.5 Механизмы туннелирования

После распространения информации о принадлежности к VPRN могут быть построены туннели, составляющие ядро VPRN.

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

Другим вариантом является использование туннелей «точка — много точек», обеспечиваемых MPLS. Как отмечено в [38], MPLS можно рассматривать как форму IP-туннелирования, поскольку метки в пакетах MPLS позволяют отвязать принятие решений о маршрутизации от адресной информации в самих пакетах. Механизмы распространения меток MPLS могут служить для связывания конкретного множества меток MPLS с определенными адресными префиксами VPRN, поддерживаемых на конкретных точках выхода (т.е., оконечных соединениях граничных маршрутизаторов), и, следовательно, другим граничным маршрутизаторам обеспечивается возможность явно помечать и маршрутизировать трафик в конкретные оконечные каналы VPRN.

Одним из привлекательных результатов использования MPLS в качестве туннельного механизма является снижение издержек на обработку в каждом граничном маршрутизаторе по сравнению с другими механизмами туннелирования. Это обусловлено тем, что защита данных в сети MPLS неявно обеспечивается явным связыванием меток, по аналогии с ориентированными на соединения сетями типа Frame Relay. Это может, следовательно, уменьшить опасения заказчиков в плане безопасности данных и снизить издержки на ресурсоемкие средства защиты (например, IPSec). Однако с MPLS связаны другие потенциальные проблемы безопасности. Здесь нет прямой поддержки таких защитных функций, как аутентификация, защита конфиденциальности и невозможность отказа, а модель доверия для MPLS предполагает, что промежуточные маршрутизаторы (которые могут располагаться в других административных доменах), через которые передается информация о принадлежности и доступности, должны быть доверенными, как и сами граничные маршрутизаторы.

5.4 Многодомные оконечные маршрутизаторы

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

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

5.5 Поддержка групповой адресации

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

5.5.1 Граничная репликация

В этом варианте каждый граничный маршрутизатор VPRN реплицирует multicast-трафик для передачи через каждый канал в VPRN. Отметим, что такую же операцию выполняют маршрутизаторы CPE, завершающие физические каналы или выделенные соединения. Как и в случае с маршрутизаторами CPE протоколы групповой маршрутизации могут работать на каждом граничном маршрутизаторе VPRN для определения дерева распространения группового трафика и, следовательно, снижения уровня ненужного лавинного трафика. Это можно реализовать с помощью экземпляров стандартных протоколов групповой маршрутизации (например, PIM⁴⁴ [39] или DVMRP⁴⁵ [40]) между всеми граничными маршрутизаторами VPRN через туннели VPRN так же, как обычные протоколы маршрутизации могут работать на каждом граничном маршрутизаторе VPRN для определения доступности внутри VPN (см. параграф 5.3.4). Другим вариантом может служить использование протоколов доступности канала на туннелях VPRN для определения доступности внутри VPRN, который дополнительно может позволять граничным маршрутизаторам VPRN индицировать конкретные группы, запрашивающие прием информации на каждом сайте, а также источники групповой информации на каждом сайте.

В любом случае требуется тот или иной механизм, который позволил бы граничным маршрутизаторам VPRN определять какие конкретные multicast-группы были запрошены и какие источники имеются на каждом сайте. Реализация такого механизма в общем случае определяется возможностями оконечных маршрутизаторов CPE на каждом сайте. Если используются протоколы групповой маршрутизации, они могут напрямую взаимодействовать с эквивалентными протоколами на каждом граничном маршрутизаторе VPRN. Если CPE не использует протоколов групповой маршрутизации тогда в отсутствии IGMP⁴⁶-прокси [41] пользовательский сайт будет ограничен одной подсетью, подключенной к граничному маршрутизатору VPRN через устройство с функциями моста, поскольку область действия сообщений IGMP ограничена подсетью. Однако за счет применения IGMP-прокси маршрутизатор CPE может реализовать групповую пересылку без использования протокола групповой маршрутизации (с некоторыми топологическими ограничениями). На своих интерфейсах в сторону пользовательского сайта маршрутизатор CPE выполняет функции маршрутизации IGMP, а на интерфейсе к граничному маршрутизатору VPRN — функции хоста IGMP.

5.5.2 Естественная поддержка групповой адресации

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

Например, каждый маршрутизатор VPRN может добавлять перед групповым адресом в каждой VPRN идентификатор VPN-ID для данной VPRN и распространять такую связку далее, трактуя пару «VPN-ID-групповой адрес внутри VPRN», как обычный групповой адрес в рамках магистральных протоколов групповой маршрутизации, как это делается в рассмотренном выше случае доступности индивидуальных адресов. Механизмы группового распространения меток MPLS могут применяться для организации подходящих групповых LSP с целью соединения сайтов внутри каждой VPRN, поддерживающей конкретные групповые адреса. Отметим, однако, что это потребует от каждого промежуточного LSR не только знать о multicast-группах внутри VPRN, но и поддерживать интерпретацию измененных анонсов. Могут быть также определены механизмы отображения multicast-групп из VPRN на группы опорной сети.

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

С использованием естественной поддержки групповой адресации связан вопрос обеспечения защиты для multicast-трафика. В отличие от случая с граничной репликацией, где наследуются параметры защиты туннеля, для естественной поддержки группового трафика потребуется применение тех или иных механизмов защиты multicast-трафика. Разработка архитектуры и решений по защите группового трафика является областью исследований (см., например, [42] и [43]). Рабочая группа SMuG⁴⁷ в рамках IRTF подготовила прототипы решений, которые были переданы в рабочую группу IETF IPSec для стандартизации.

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

5.6 Рекомендации

Множество предложений, разработанных для поддержки тех или иных форм функциональности VPRN, можно разделить на две больших группы — в одной используется модель добавления в пакеты протоколов маршрутизации для распространения сведений о принадлежности к VPN и/или доступности ([13],[15]), а в другой те же цели достигаются за счет применения виртуальных маршрутизаторов ([12],[14]). В некоторых случаях описанные механизмы опираются на свойства конкретной архитектуры (например, MPLS), а не IP.

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

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

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

6.0 Типы VPN — коммутируемые соединения

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

Сегодня во многих корпоративных сетях разрешен доступ пользователей по коммутируемым линиям через сети PSTN, когда пользователь организует соединение PPP с сервером доступа, на котором сессия PPP аутентифицируется с использованием систем AAA на основе стандартных протоколов типа Radius [44]. С учетом повсеместного развертывания подобных систем любая система VPDN на практике должна позволять почти прозрачное взаимодействие с ними.

В рамках IETF был разработан протокол L2TP⁴⁹ [8], который позволяет организовывать пользовательские сессии PPP через связку между LAC⁵⁰ и удаленным сервером LNS⁵¹. Сам протокол L2TP основан на двух более ранних протоколах — L2F⁵² [45] и PPTP⁵³ [46], что отразилось в двух достаточно разных сценариях применения L2TP (вынужденное и добровольное туннелирование), описанных в параграфах 6.2 и 6.3.

В этом документе рассматривается применение L2TP в сетях IP (с использованием UDP), но протокол L2TP может и напрямую работать «поверх» таких протоколов, как ATM или Frame Relay. Вопросы, связанные с использованием L2TP в сетях без протокола IP (например, защита туннелей), в этом документе не рассматриваются.

6.1 Характеристики протокола L2TP

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

6.1.1 Мультиплексирование

L2TP имеет встроенную поддержку мультиплексирования вызовов множества пользователей через один канал. Между парой конечных точек IP может существовать множество туннелей L2TP (различаются по tunnel-id), а через один туннель может быть организовано множество сессий (различаются по session-id).

6.1.2 Сигнализация

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

6.1.3 Защита данных

Обеспечивая прозрачное расширение PPP для пользователей через связку от LAC до LNS, протокол L2TP позволяет для организации соединений и передачи данных применять любые механизмы защиты, которые могут использоваться с обычными соединениями PPP. Однако это не обеспечивает защиты для самого протокола L2TP. По этой причине для защиты L2TP можно использовать его совместно с IPSec для сетей IP [47], [48] или аналогичными механизмами для опорных сетей без IP [49].

Взаимодействие L2TP с системами AAA для аутентификации и проверки полномочий пользователей зависит от конкретного применения L2TP и устройств, поддерживающих функции LAC и LNS. Эти вопросы подробно рассмотрены в [50].

Средства определения хостом корректного LAC для подключения и определения устройством LAC пользователей для направления трафика в туннель, а также параметры LNS, связанные с каждым пользователем, выходят за рамки VPDN. Эти вопросы могут быть решены, например, с помощью спецификаций Internet-роуминга [51].

6.1.4 Мультипротокольный транспорт

L2TP транспортирует пакеты PPP (и только их) и, таким образом, может служить для поддержки мультипротокольного трафика, поскольку PPP является мультипротокольным.

6.1.5 Упорядочивание

L2TP поддерживает упорядоченную доставку пакетов. Эта возможность может быть согласована при организации сессии, а также может быть отключена или включена LNS непосредственно в сессии. Поле порядкового номера в L2TP может также служить для индикации отбрасывания пакетов, которая нужна для корректной работы разных алгоритмов сжатия PPP. Если сжатие не используется и LNS считает, что используемому протоколу (указанному при согласовании PPP NCP) не требуется упорядоченной доставки пакетов (например, IP), сохранение порядка может быть отключено.

6.1.6 Поддержка туннелей

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

6.1.7 Большие MTU

Протокол L2TP не имеет встроенной поддержки фрагментации и сборки пакетов, но при необходимости может воспользоваться IP для случаев работы «поверх» UDP/IP. Отметим, что устройства LAC и LNS для предотвращения фрагментации могут изменять значение MRU⁵⁴, согласованное через PPP, если им известно значение MTU на пути между LAC и LNS. Для этого предложено разрешить применение MTU в тех случаях, когда L2TP служит для транспортировки IP [52].

6.1.8 Туннельные издержки

L2TP при использовании в сетях IP работает на основе транспорта UDP и должен применяться для переноса трафика PPP. Это приводит к значительным издержкам как на уровне данных в заголовках UDP, L2TP и PPP, так и на уровне управления L2TP и PPP. Более подробно эти вопросы рассмотрены в параграфе 6.3.

6.1.9 Управление потоками и контроль перегрузок

L2TP поддерживает механизмы управления потоками и контроля перегрузок для протокола управления, но не для трафика данных. Более подробная информация приведена в параграфе 3.1.9.

6.1.10 QoS и управление трафиком

Заголовок L2TP содержит 1-битовое поле приоритета, которое может быть установлено для пакетов, обладающих преимуществами (например, keepalive) при размещении в локальных очередях и передаче. Благодаря прозрачному расширению PPP, L2TP имеет встроенную поддержку таких механизмов PPP, как multi-link PPP [53] и связанные с ним протоколы управления [54], что позволяет управлять полосой канала по запросам пользователей.

Кроме того, вызовы L2TP могут отображаться на базовые механизмы управления трафиком, которые могут существовать в сети, и есть предложения по передаче через сигнализацию L2TP запросов на выбор дифференцированного обслуживания [55].

6.1.11 Разное

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

6.2 Вынужденное туннелирование

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

Существует множество разных сценариев развертывания. В одном из примеров, показанном на рисунке, абонентский хост соединяется с NAS, действующим в качестве LAC, и организуется туннель через сеть IP (например, Internet) до шлюза, действующего как LNS. Шлюз обеспечивает доступ в корпоративную сеть и может быть устройством данной сети или граничным маршрутизатором ISP, если поддержка функций LNS передана на обслуживание ISP. Другим примером может служить использование ISP протокола L2TP для предоставления пользователям доступа в Internet. Пользовательский хост соединяется с NAS, действующим в качестве LAC, и организуется туннель через сеть доступа до граничного маршрутизатора ISP, который служит LNS. Этот граничный маршрутизатор ISP пробрасывает пользовательский трафик в Internet. В других сценариях ISP применяет L2TP для обеспечения пользователям доступа в VPRN или одновременного соединения с VPRN и Internet.

VPDN с использованием вынужденного или добровольного туннелирования можно рассматривать как другой метод доступа для пользовательского трафика, который может обеспечивать соединения между разными типами сетей (например, корпоративная сеть, Internet или VPRN). Последний вариант может также служить примером обеспечения услуг VPN для случая разнотипных VPN.

10.0.0.1
+----+
|Хост|-----    LAC      -------------     LNS        10.0.0.0/8
+----+   /   +-----+   (             )   +-----+     ---------
        /----| NAS |---( Опорная сеть)---| GW  |----(Корпорат.)
коммутируемое+-----+   (      IP     )   +-----+    (  сеть   )
соединение              -------------                ---------

                <------- Туннель L2TP ------->

    <--------------------- Сессия PPP ------->

Рисунок 6.1. Пример вынужденного туннелирования.

Вынужденное туннелирование изначально предназначалось для развертывания серверов доступа с поддержкой коммутируемых линий, позволяющих подключаться через сети общего пользования к корпоративным сайтам без необходимости организовывать на этих сайтах свои серверы доступа. Другим примером может служить передача ISP функций доступа по телефонным линиям сторонней организации (такой, как LEC⁵⁵ в США), которая обслуживает множество ISP. Позднее было предложено использовать вынужденное туннелирование для служб DSL⁵⁶ [56] [57], использующих существующую инфраструктуру AAA.

Маршрутизация вызовов для вынужденного туннелирования требует возможности использования некоторых аспектов организации соединений PPP, позволяющих LAC определить идентичность LNS. Как отмечено в [50], эти аспекты могут включать идентификацию пользователей с помощью тех или иных сети доступа или атрибутов вызывающей стороны (например, FQDN⁵⁷) для использования в процедурах аутентификации PPP.

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

6.3 Добровольные туннели

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

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

6.3.1 Вопросы использования L2TP для добровольных туннелей

Спецификация протокола L2TP поддерживает добровольное туннелирование, поскольку LAC может размещаться на хостах, а не только на узлах сети. Отметим, что такой хост имеет два адреса IP — один для туннеля LAC-LNS, а другой (обычно выделяется протоколом PPP) — для сети, к которой этот хост подключается. Преимущество использования L2TP для добровольного туннелирования заключается в возможности применения имеющихся механизмов аутентификации и выделения адресов PPP без каких-либо изменений. Например, LNS может включать клиент Radius и взаимодействовать с сервером Radius для аутентификационного обмена PPP PAP или CHAP, а также для получения конфигурационных данных для хоста (IP-адрес и список серверов DNS). Эта информация может быть передана хосту по протоколу PPP IPCP.

10.0.0.1
+----+
|Host|-----             -------------                10.0.0.0/8
+----+   /   +-----+   (             )   +-----+     ---------
        /----| NAS |---( Опорная сеть)---| GW  |----(Корпорат.)
коммутируемое+-----+   (      IP     )   +-----+    (  сеть   )
соединение              -------------                ---------

               <------- Туннель L2TP ------->
                        с                      LAC на хосте
  <-------------- сессией PPP -------------->  LNS на шлюзе

                     или
  <-------------- туннель IPSEC ------------>

Рисунок 6.2. Пример добровольного туннелирования.

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

HTTP/TCP/IP/PPP/L2TP/UDP/ESP/IP/PPP/AHDLC

В работе [58] предложено снижать издержки для добровольных туннелей за счет использования только IPSec

HTTP/TCP/IP/ESP/IP/PPP/AHDLC

В этом случае IPSec используется в туннельном режиме и туннель завершается на граничном шлюзе IPSec в сети предприятия или граничном маршрутизаторе провайдера, подключенном к корпоративной сети. Для адресации хоста есть два варианта. Может использоваться два адреса, как в случае L2TP. Хост может также использовать один публичный адрес IP в поле источника для внутренних и внешних заголовков IP при использовании шлюза NAT⁵⁸ на пути пересылки пакетов в корпоративную сеть. Для других хостов корпоративной сети хост всегда будет виден с «внутренним» адресом IP. Использование NAT связано с некоторыми ограничениями, рассмотренными в [58].

Другой возможной проблемой, связанной с PPP, является тот факт, что характеристики канального уровня в туннеле L2TP через опорную сеть IP достаточно сильно отличаются от характеристик канального уровня на последовательной линии, как указано в спецификации L2TP. Например, неаккуратно выбранные параметры PPP могут приводить к частым сбросам и тайм-аутам, особенно при использовании компрессии. Это связано с тем, что туннель L2TP может изменять порядок следования пакетов, а также отбрасывать их без уведомления, чего обычно не происходит в последовательных линиях. Частота потери пакетов также может оказаться значительно выше в результате перегрузок в сети. Использование порядковых номеров в заголовках L2TP позволяет решить проблему нарушения порядка и для случаев, когда LAC и LNS являются конечными точками PPP (как при добровольном туннелировании) поле порядкового номера может применяться для обнаружения отбрасывания пакетов и передачи соответствующей информации функциям компрессии, которым эти данные позволяют поддерживать синхронизацию сторон. Однако проблема сохраняется для вынужденного туннелирования, поскольку в этом случае LAC может осознанно передавать поврежденные кадры хосту PPP для индикации потери пакетов, но часть оборудования не будет это позволять.

6.3.2 Вопросы использования IPSec для добровольных туннелей

При использовании IPSec для добровольного туннелирования функции аутентификации пользователей и настройки конфигурации хоста, выполняемые с помощью PPP, для случая L2TP также нужно обеспечивать. Следует отметить различия между аутентификацией пользователя и аутентификацией устройства. Двухфакторная аутентификация выполняется с использованием двух элементов из числа перечисленных — компьютер или смарт-карта с цифровым сертификатом, пароль пользователя и т. п. (вариант двухфакторной аутентификации используется в банкоматах — нужно предъявить карту и номер PIN). Многие из унаследованных систем аутентификации пользователей асимметричны по своей природе и не могут поддерживаться IKE. Для систем удаленного доступа в большинстве случаев применяется аутентификация PPP между пользователем и сервером доступа и Radius между серверами доступа и аутентификации. Аутентификационный обмен в этом случае (например, PAP или CHAP) является асимметричным. CHAP поддерживает возможность повтора аутентификации пользователя в любой момент в течение сессии для проверки того, что пользователем является тот же человек, который организовал сеанс.

Протокол IKE обеспечивает строгую аутентификацию машин, однако поддержка аутентификации пользователей ограничена и асимметричная аутентификация пользователей не поддерживается. Хотя пользовательский пароль может применяться для создания ключей, используемых в качестве preshared, его невозможно использовать с IKE Main Mode в среде удаленного доступа, поскольку у пользователя не будет фиксированного адреса IP, а в режиме Aggressive Mode не обеспечивается защиту идентичности. По этой причине предложено множество решений для поддержки традиционных схем асимметричной аутентификации пользователей с IPSec. В работе [59] определен новый обмен сообщениями IKE (transaction exchange), разрешающий последовательности сообщений Request/Reply и Set/Acknowledge, а также определены атрибуты, которые могут применяться для настройки клиентского стека IP. В работах [60] и [61] описаны механизмы использования такого обмена сообщениями в промежутке между обменами IKE Phase 1 и Phase 2 для аутентификации пользователей. Другое предложение (без расширения самого протокола IKE) описано в [62]. В этой модели пользователь организует Phase 1 SA со шлюзом защиты, а потом организует Phase 2 SA со шлюзом, через который работает существующий протокол аутентификации. Шлюз служит посредником и транслирует протокольные сообщения серверу аутентификации.

Кроме того, были предложения настраивать для удаленного хоста адрес IP и другие протоколы конфигурации через IPSec. Например, в работе [63] описан метод, в котором удаленный хост сначала организует Phase 1 SA с защитным шлюзом, а затем Phase 2 SA со шлюзом, через который работает протокол DHCP. Шлюз служит посредником и транслирует протокольные сообщения серверу DHCP. Подобно предложению из [62], здесь не вносится изменений в сам протокол IKE.

Еще один аспект функциональности PPP, поддержка которого может потребоваться в мультипротокольной среде, — это необходимость передачи протоколов сетевого уровня, отличных от IP, и даже протоколов канального уровня (например, Ethernet) для организации мостов через IPSec. Этот вопрос рассмотрен в параграфе 3.1.4.

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

6.4 Хосты в локальных сетях

Основанная на протоколе PPP современная модель доступа по коммутируемым линиям предполагает прямое соединение хоста с ориентированной на соединения телефонной сетью. Разработанные позднее новые технологии доступа (например, DSL) пытались воспользоваться это моделью [57], чтобы сохранить существующие системы AAA. Однако распространение ПК, принтеров и других сетевых приложений в домах и небольших компаниях, а также снижение стоимости сетей породили альтернативу модели прямого подключения хостов. В результате возникла модель подключения хостов к Internet через небольшие (обычно, Ethernet) локальные сети.

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

6.4.1 Расширение PPP на хосты с использованием L2TP

Было внесено множество предложений (например, [56]) по расширению L2TP через Ethernet, позволяющему сетевым хостам организовывать сессии PPP за пределы сети так же, как это делается для обычных хостов.

6.4.2 Непосредственное расширение PPP на хосты

Существует также спецификация для отображения PPP непосредственно в Ethernet (PPPOE) [64], в которой используется широковещательный механизм для обеспечения хостам возможности поиска серверов доступа для подключения к ним. Такие серверы могут при необходимости туннелировать сессии PPP дальше, используя L2TP или похожий механизм.

6.4.3 Использование IPSec

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

Отметим, что для всех этих методов на хостах требуется использовать дополнительные программы, которые поддерживают функциональность LAC, клиента PPPOE или клиента IPSec.

6.5 Рекомендации

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

Для добровольных туннелей с применением IPSec требуется дополнительная работа с целью обеспечить поддержку:

• традиционной асимметричной аутентификации пользователей (6.3);

• выделение адресов и настройку конфигурации хостов (6.3).

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

7.0 Типы VPN — VPLS

VPLS⁵⁹ представляет собой эмуляцию сегмента ЛВС с использованием Internet. VPLS может использоваться для организации прозрачного транспорта TLS⁶⁰, который может служить для соединения множества оконечных узлов CPE (мостов и маршрутизаторов) независимо от протоколов. VPLS эмулирует сегмент ЛВС через сеть IP так же, как LANE эмулирует сегмент ЛВС через сеть ATM. Основным преимуществом VPLS является полная прозрачность для протоколов, что может быть важно как с точки зрения поддержки разных протоколов, так и в плане выполнения требований регуляторов в контексте конкретных сервис-провайдеров.

10.1.1.1    +--------+                       +--------+    10.1.1.2
+---+       |краевой |     туннель IP        |краевой |       +---+
|CPE|-------| узел   |-----------------------| узел   |-------|CPE|
+---+оконеч.| ISP    |                       | ISP    |оконеч.+---+
     канал  +--------+                       +--------+канал 
                 ^  |                         |   ^
                 |  |     ---------------     |   |
                 |  |    (               )    |   |
                 |  +----( магистраль IP )----+   |
                 |       (               )        |
                 |        ---------------         |
                 |               |                |
                 |туннель IP +--------+ туннель IP|
                 |           |краевой |           |
                 +-----------| узел   |-----------+
                             | ISP    |
                             +--------+   подсеть = 10.1.1.0/24
                                 |
                 оконечный канал |
                                 |
                               +---+
                               |CPE| 10.1.1.3
                               +---+

Рисунок 7.1. Пример VPLS.

7.1 Требования VPLS

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

7.1.1 Протоколы туннелирования

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

7.1.2 Поддержка групповой и широковещательной адресации

Для VPLS требуется поддержка широковещания. Это нужно как для широковещательных кадров, так и для лавинной рассылки пакетов на канальном уровне, когда индивидуальный (unicast) кадр рассылается всем (лавинно) по причине отсутствия данных о пути к адресату. Протокол преобразования адресов, работающий в сети на базе мостов, обычно тоже использует широковещательные кадры (например, ARP). Набор механизмов с поддержкой группового трафика, рассмотренный выше для VPRN, может использоваться и для VPLS, хотя более частое в общем случае применение широковещания в VPLS может оказывать сильное давление на естественную поддержку групповой адресации (например, снизить издержки репликации на граничных узлах VPLS).

7.1.3 Конфигурация принадлежности к VPLS и топология

Настройка конфигурации VPLS аналогична случаю VPRN, поскольку требует лишь информации о локальной связи каналов с VPN только для данного граничного узла VPLS и идентификация других граничных маршрутизаторов VPLS или маршрутов к ним. В частности, конфигурация не зависит от природы пересылки на каждом граничном узле VPN. Поэтому все механизмы определения принадлежности к VPN и распространения этой информации, описанные выше для VPRN, применимы и для конфигурации VPLS. Как и для случая VPRN, топологией VPLS можно легко управлять на уровне конфигурации партнерских узлов в каждом граничном маршрутизаторе VPLS в предположении, что механизм распространения информации о принадлежности позволяет это делать. Ясно, что типовая VPLS будет полносвязной, однако для исключения необходимости передачи трафика между двумя узлами VPLS через третий (транзитный) узел VPLS требуется использовать протокол Spanning Tree [65] предотвращающий возникновение петель.

7.1.4 Типы оконечных узлов CPE

VPLS может поддерживать в качестве устройств CPE мосты или маршрутизаторы.

CPE-маршрутизаторами будут прозрачно организовывать партнерские связи через VPLS без необходимости организации между ними партнерских отношений в рамках VPLS. Проблемы масштабирования, возникающие для полносвязной топологии VPRN, применимы и для этого случая, но в данной ситуации число маршрутизаторов-партнеров потенциально больше, поскольку маршрутизаторы ISP не являются больше точками агрегирования.

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

Природа CPE определяет протоколы инкапсуляции, адресации, пересылки и определения доступности в VPLS, которые будут рассмотрены ниже.

7.1.5 Инкапсуляция пакетов оконечного канала

7.1.5.1 CPE-мост

В этом случае пакеты передаются в сеть VPLS и из нее через канал доступа в кадрах канального уровня с подходящей для канала доступа инкапсуляцией. Наиболее частым является использование кадров Ethernet к подходящей для конкретной технологии доступа инкапсуляцией (например, использование ATM для подключения мостов CPE к граничным узлам VPLS). Такие кадры тогда пересылаются на уровне 2 в туннель, используемый в VPLS. Как было отмечено выше, это требует использовать протокол туннелирования IP, позволяющий транспортировать такие кадры канального уровня. Отметим, что это обязательно не всегда, однако применение поля идентификации протокола в каждом туннельном пакете, как природа инкапсулированного трафика (например, кадров Ethernet) может быть указано при организации туннеля.

7.1.5.2 CPE-маршрутизатор

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

7.1.6 Адресация CPE и трансляция адресов

7.1.6.1 CPE-мост

Поскольку VPLS работает на канальном уровне, все хосты на оконечных сайтах в случае CPE-моста обычно будут находиться в одной подсети (возможно и наличие множества подсетей в одной ЛВС, но такие случаи не типичны). Кадры пересылаются в VPLS и через нее на основе адресов канального уровня (например, IEEE MAC), связанных с отдельными хостами. В VPLS требуется поддержка широковещательного трафика, поскольку он обычно используется механизмами преобразования адресов для отображения адресов сетевого уровня на адреса канального уровня. Для VPLS требуются также алгоритмы пересылки и определения доступности с целью обработки лавинного трафика.

7.1.6.2 CPE-маршрутизатор

Для соединения маршрутизаторов CPE через VPLS обычно применяется одна подсеть сетевого уровня. Хосты за каждым маршрутизатором CPE находятся в разных подсетях сетевого уровня. Маршрутизаторы CPE передают пакеты через VPLS отображая сетевой адрес следующего интервала на адрес партнерского маршрутизатора на канальном уровне. Инкапсуляция канального уровня (обычно Ethernet) используется как для случая мостов.

Однако, как отмечено выше, в случаях, когда все узлы CPE, подключенные к VPLS, являются маршрутизаторами, по причине ограничений адресного пространства VPLS для инкапсуляции может применяться адресное пространство, отличное от MAC. Например, в [11] предложен механизм для организации VPLS через сети MPLS, основанный на более раннем механизме организации VPRN через MPLS [38], где предлагается использовать MPLS в качестве механизма туннелирования и локально присваивать метки MPLS в качестве адресов канального уровня для идентификации маршрутизаторов CPE LSR, соединенных с VPLS.

7.1.7 Механизмы пересылки и доступности для краевых узлов VPLS

7.1.7.1 CPE-мост

Единственным практичным механизмом пересылки на границе VPLS в этом случае будет стандартная лавинная рассылка пакетов на канальном уровне и определение MAC-адресов, как описано в [65]. По этой причине нет необходимости в отдельном протоколе проверки доступности для VPLS, хотя нужен широковещательный механизм для лавинной рассылки, как отмечено выше. В общем случае нет необходимости поддерживать протокол Spanning Tree между граничными узлами VPLS, если топология VPLS такова, что граничные узла VPLS не используются для транзита трафика между любыми другими узлами VPLS (иными словами, имеется полная связность и транзит явно исключается). С другой стороны, CPE-мосты могут реализовать протокол остовного дерева для защиты от возникновения «обходных путей» мимо VPLS.

7.1.7.2 CPE-маршрутизатор

В этом случае могут использоваться стандартные технологии мостов. Кроме того, меньшее адресное пространство канального уровня в такой VPLS позволяет также использовать другие технологии с явными маршрутами канального уровня между маршрутизаторами CPE. В работе [11], например, предложено при добавлении в VPLS нового маршрутизатора CPE организовывать MPLS LSP между всеми CPE LSR. Это позволяет избавиться от необходимости лавинной рассылки пакетов. В более общем случае при использовании механизмов доступности для настройки в конфигурации граничных узлов VPLS адресов канального уровня подключенных к узлу маршрутизаторов CPE, модификации всех механизмов определения доступности внутри VPN, рассмотренные для VPRN, могут использоваться для распространения информации о доступности всем другим граничным узлам VPLS. Это позволяет организовать передачу пакетов через VPLS без лавинной рассылки.

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

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

7.2 Рекомендации

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

8.0 Итоговые рекомендации

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

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

Для IKE/IPSec:

• транспортировка VPN-ID при организации SA (3.1.2);

• опции пустых (null) шифрования и аутентификации (3.1.3);

• мультипротокольная работа (3.1.4);

• упорядочение кадров (3.1.5);

• традиционная асимметричная аутентификация пользователей (6.3);

• выделение и настройка адресов хостов (6.3).

Для L2TP:

• определение режимов работы IPSec при использовании для поддержки L2TP (3.2).

Для VPN в целом:

• определение механизмов настройки и распространения информации о принадлежности к VPN на основе каталога или MIB (5.3.2);

• обеспечение в новых разработках поддержки максимального числа типов VPN вместо создания решений для единственного типа VPN.

9.0 Вопросы безопасности

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

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

Спасибо Anthony Alles из Nortel Networks за его помощь при написании этого документа и разработку значительной части материала, на котором были основаны ранние версии документа. Спасибо также Joel Halpern за его полезные комментарии.

11.0 Литература

[1] ATM Forum. «LAN Emulation over ATM 1.0», af-lane-0021.000, January 1995.

[2] ATM Forum. «Multi-Protocol Over ATM Specification v1.0», af-mpoa-0087.000, June 1997.

[3] Ferguson, P. and Huston, G. «What is a VPN?», Revision 1, April 1 1998; http://www.employees.org/~ferguson/vpn.pdf.

[4] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[5] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, November 1998.

[6] Perkins, C., «IP Encapsulation within IP», RFC 2003, October 1996.

[7] Hanks, S., Li, T., Farinacci, D. and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 1701, October 1994.

[8] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. And B. Palter, «Layer Two Tunneling Protocol «L2TP»», RFC 2661, August 1999.

[9] Rosen, E., et al., «Multiprotocol Label Switching Architecture», Work in Progress⁶².

[10] Heinanen, J., et al., «MPLS Mappings of Generic VPN Mechanisms», Work in Progress.

[11] Jamieson, D., et al., «MPLS VPN Architecture», Work in Progress.

[12] Casey, L., et al., «IP VPN Realization using MPLS Tunnels», Work in Progress.

[13] Li, T. «CPE based VPNs using MPLS», Work in Progress.

[14] Muthukrishnan, K. and A. Malis, «Core MPLS IP VPN Architecture», Work in Progress⁶³.

[15] Rosen, E. and Y. Rekhter, «BGP/MPLS VPNs», RFC 2547, March 1999.

[16] Fox, B. and B. Gleeson, «Virtual Private Networks Identifier», RFC 2685, September 1999.

[17] Petri, B. (editor) «MPOA v1.1 Addendum on VPN support», ATM Forum, af-mpoa-0129.000.

[18] Harkins, D. and C. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

[19] Calhoun, P., et al., «Tunnel Establishment Protocol», Work in Progress.

[20] Andersson, L., et al., «LDP Specification», Work in Progress⁶⁵.

[21] Jamoussi, B., et al., «Constraint-Based LSP Setup using LDP» Work in Progress⁶⁶.

[22] Awduche, D., et al., «Extensions to RSVP for LSP Tunnels», Work in Progress.

[23] Kent, S. and R. Atkinson, «IP Encapsulating Security Protocol (ESP)», RFC 2406, November 1998.

[24] Simpson, W., Editor, «The Point-to-Point Protocol (PPP)», STD 51, RFC 1661, July 1994.

[25] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. And A. Malis, «ATM Signalling Support for IP over ATM», RFC 1755, February 1995.

[26] Malkin, G. «RIP Version 2 Carrying Additional Information», RFC 1723, November 1994.

[27] Moy, J., «OSPF Version 2», STD 54, RFC 2328, April 1998.

[28] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, «IP Payload Compression Protocol (IPComp)», RFC 2393, December 1998.

[29] Duffield N., et al., «A Performance Oriented Service Interface for Virtual Private Networks», Work in Progress.

[30] Jacobson, V., Nichols, K. and B. Poduri, «An Expedited Forwarding PHB», RFC 2598, June 1999.

[31] Casey, L., «An extended IP VPN Architecture», Work in Progress.

[32] Rekhter, Y., and T. Li, «A Border Gateway Protocol 4 (BGP-4),» RFC 1771, March 1995.

[33] Grossman, D. and J. Heinanen, «Multiprotocol Encapsulation over ATM Adaptation Layer 5», RFC 2684, September 1999.

[34] Wahl, M., Howes, T. and S. Kille, «Lightweight Directory Access Protocol (v3)», RFC 2251, December 1997.

[35] Boyle, J., et al., «The COPS (Common Open Policy Service) Protocol», RFC 2748, January 2000.

[36] MacRae, M. and S. Ayandeh, «Using COPS for VPN Connectivity» Work in Progress.

[37] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[38] Heinanen, J. and E. Rosen, «VPN Support with MPLS», Work in Progress.

[39] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, «Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification», RFC 2362, June 1998.

[40] Waitzman, D., Partridge, C., and S. Deering, «Distance Vector Multicast Routing Protocol», RFC 1075, November 1988.

[41] Fenner, W., «IGMP-based Multicast Forwarding (IGMP Proxying)», Work in Progress.

[42] Wallner, D., Harder, E. and R. Agee, «Key Management for Multicast: Issues and Architectures», RFC 2627, June 1999.

[43] Hardjono, T., et al., «Secure IP Multicast: Problem areas, Framework, and Building Blocks», Work in Progress.

[44] Rigney, C., Rubens, A., Simpson, W. and S. Willens, «Remote Authentication Dial In User Service (RADIUS)», RFC 2138, April 1997.

[45] Valencia, A., Littlewood, M. and T. Kolar, «Cisco Layer Two Forwarding (Protocol) «L2F»», RFC 2341, May 1998.

[46] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. And G. Zorn, «Point-to-Point Tunneling Protocol (PPTP)», RFC 2637, July 1999.

[47] Patel, B., et al., «Securing L2TP using IPSEC», Work in Progress.

[48] Srisuresh, P., «Secure Remote Access with L2TP», Work in Progress.

[49] Calhoun, P., et al., «Layer Two Tunneling Protocol «L2TP» Security Extensions for Non-IP networks», Work in Progress.

[50] Aboba, B. and Zorn, G. «Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS», Work in progress.

[51] Aboba, B. and G. Zorn, «Criteria for Evaluating Roaming Protocols», RFC 2477, January 1999.

[52] Shea, R., «L2TP-over-IP Path MTU Discovery (L2TPMTU)», Work in Progress.

[53] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, «The PPP Multilink Protocol (MP)», RFC 1990, August 1996.

[54] Richards, C. and K. Smith, «The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)», RFC 2125, March 1997.

[55] Calhoun, P. and K. Peirce, «Layer Two Tunneling Protocol «L2TP» IP Differential Services Extension», Work in Progress.

[56] ADSL Forum. «An Interoperable End-to-end Broadband Service Architecture over ADSL Systems (Version 3.0)», ADSL Forum 97-215.

[57] ADSL Forum. «Core Network Architectures for ADSL Access Systems (Version 1.01)», ADSL Forum 98-017.

[58] Gupta, V., «Secure, Remote Access over the Internet using IPSec», Work in Progress.

[59] Pereira, R., et al., «The ISAKMP Configuration Method», Work in Progress.

[60] Pereira, R. and S. Beaulieu, «Extended Authentication Within ISAKMP/Oakley», Work in Progress.

[61] Litvin, M., et al., «A Hybrid Authentication Mode for IKE», Work in Progress.

[62] Kelly, S., et al., «User-level Authentication Mechanisms for IPsec», Work in Progress.

[63] Patel, B., et al., «DHCP Configuration of IPSEC Tunnel Mode», Work in Progress.

[64] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D. and R. Wheeler, «A Method for Transmitting PPP Over Ethernet (PPPoE)», RFC 2516, February 1999.

[65] ANSI/IEEE — 10038: 1993 (ISO/IEC) Information technology — Telecommunications and information exchange between systems — Local area networks — Media access control (MAC) bridges, ANSI/IEEE Std 802.1D, 1993 Edition.

12.0 Сведения об авторах

Bryan Gleeson

Nortel Networks

4500 Great America Parkway

Santa Clara CA 95054

USA

Phone: +1 (408) 548 3711

EMail: bgleeson@shastanets.com

Juha Heinanen

Telia Finland, Inc.

Myyrmaentie 2

01600 VANTAA

Finland

Phone: +358 303 944 808

EMail: jh@telia.fi

Arthur Lin

Nortel Networks

4500 Great America Parkway

Santa Clara CA 95054

USA

Phone: +1 (408) 548 3788

EMail: alin@shastanets.com

Grenville Armitage

Bell Labs Research Silicon Valley

Lucent Technologies

3180 Porter Drive,

Palo Alto, CA 94304

USA

EMail: gja@lucent.com

Andrew G. Malis

Lucent Technologies

1 Robbins Road

Westford, MA 01886

USA

Phone: +1 978 952 7414

EMail: amalis@lucent.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

13.0 Полное заявление авторских прав

Copyright (C) The Internet Society (2000). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

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

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

Network Working Group                                         R. Yavatkar
Request for Comments: 2753                                          Intel
Category: Informational                                     D. Pendarakis
                                                                      IBM
                                                                R. Guerin
                                                       U. Of Pennsylvania
                                                             January 2000

Модель контроля доступа на основе правил

A Framework for Policy-based Admission Control

PDF

Статус документа

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

Авторские права

Copyright (C) The Internet Society (2000). All Rights Reserved.

1. Введение

Рабочие группы IETF, такие как Integrated Services¹ (int-serv) и RSVP [1] подготовили расширения архитектуры IP и модели обслуживания «по возможности» (best-effort), позволяющие приложениям и конечным пользователям запрашивать определенное качество (уровень) обслуживания от сети в дополнение к современным услугам IP best-effort. Недавние результаты рабочей группы Differentiated Services² также направлены на определение механизмов поддержки агрегатов услуг QoS³. Модель int-serv для этих новых услуг требует явной сигнализации требований QoS от конечных точек и обеспечения восприятия и управления трафиком на маршрутизаторах с интегрированным обслуживанием. Предложенные стандарты для RSVP [RFC 2205] и интегрированных услуг [RFC 2211, RFC 2212] являются примерами нового протокола организации резервирования и новых определений сервиса, соответственно. В модели int-serv некоторые потоки данных получают предпочтительное обслуживание по сравнению с другими потоками — компоненты управления восприятием (admission control) принимают во внимание лишь запросы ресурсов со стороны резервирующего и доступные возможности, но не принимают запросы QoS. Однако механизмы int-serv не включают важных аспектов управления восприятием — сетевые администраторы и сервис-провайдеры должны быть способны отслеживать, контролировать и форсировать использование ресурсов и услуг на основе правил, выводимых из таких критериев, как отождествление пользователей и приложений, потребности в пропускной способности, день недели, время суток. Механизмы diff-serv тоже должны принимать во внимание правила, включающие такие критерии, как отождествление пользователей, точки входа и т. д.

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

В разделе 2 приведены определения основных терминов. В разделе 3 указан список требований и целей механизмов, применяемых для контроля доступа и обеспечения лучшего QoS. Затем очерчены элементы архитектуры модели (раздел 4) и описана функциональность каждой компоненты. В разделе 5 приведены примеры правил, возможные варианты и поддержка политики для этих вариантов. В разделе 6 заданы требования к протоколу «клиент-сервер» для коммуникаций между сервером правил (PDP) и клиентом (PEP), а также оценена пригодность имеющихся протоколов.

2. Терминология

Ниже приведены определения используемых в документе терминов.

Administrative Domain — административный домен

Набор сетей с единым административным управлением, собранных в соответствии с административными целями.

Network Element или Node — элемент сети или узел

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

В этом документе термины «маршрутизатор», «элемент сети» и «узел сети» используются взаимозаменяемо, но все они должны рассматриваться как элементы сети.

QoS Signaling Protocol — сигнальный протокол QoS

Протокол сигнализации, передающий запросы контроля доступа к ресурсу, например, RSVP.

Policy — политика (правила)

Набор правил и услуг, где правила определяют критерии доступа и использования ресурса.

Policy control — проверка политики

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

Policy Object — объект политики

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

Policy Element — элемент политики

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

Policy Decision Point (PDP) — точка принятия решений в политике

Место, где принимается решение в политике доступа.

Policy Enforcement Point (PEP) — точка исполнения решений политики

Место, где реально исполняется решение политики доступа.

Policy Ignorant Node (PIN) — игнорирующий политику узел

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

Resource — ресурс

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

Service Provider — сервис-провайдер

Контролирует сетевую инфраструктуру и может отвечать за учет и оплату услуг.

Soft State Model — модель “мягких” состояний

Soft state представляет собой вариант модели с учетом состояний, которые истекают через некоторое время после установки в PEP или PDP. Это способ автоматического удаления состояний при наличии отказов коммуникаций или сетевых элементов. Например, RSVP применяет такую модель для установки состояний резерва на сетевых элементах в пути потока данных через сеть.

Installed State — установленное состояние

Новый и уникальный запрос от PEP к PDP, который должен удаляться явно.

Trusted Node — доверенный узел

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

3. Контроль восприятия на основе правил — цели и требования

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

Политика и механизмы

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

RSVP

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

Поддержка вытеснения

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

Поддержка разных стилей политики

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

Предоставление информации для мониторинга и учета

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

Устойчивость к отказам и восстановление

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

Поддержка узлов PIN

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

Расширяемость

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

Вопросы безопасности и атак на службы

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

4. Элементы архитектуры

Двумя основными элементами архитектуры управления политикой являются точки применения правил (PEP) и точки принятия решений (PDP). На рисунке 1 показана простая конфигурация, включающая эти элементы. PEP являются компонентами узлов сети, PDP — удаленным объектом, который может размещаться на сервере политики. PEP представляет компоненту, которая всегда работает на осведомленном о политике узле и в ней исполняются принятые решения политики, которые принимаются в основном на PDP. Сама точка PDP может использовать дополнительные механизмы и протоколы для обеспечения дополнительных функций, таких как проверка подлинности пользователей, учет, хранение правил и т. п. Например, PDP может использовать службу каталогов LDAP для хранения и поиска правил [6]. В документе не рассматриваются эти дополнительные механизмы и протоколы, в также их применение.

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

 ________________         Сервер политики
|                |        ______
|    Узел сети   |        |     |------------->
|    _____       |        |     |  Может применять LDAP,SNMP,.. для
|   |     |      |        |     |  доступа к базе правил, аутентификации и пр.
|   | PEP |<-----|------->| PDP |------------->
|   |_____|      |        |_____|
|                |
|________________|

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

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

Особое значение имеет «язык» определения правил, реализованный в PDP. Число правил, применимых к узлу сети, может быть достаточно большим. В то же время эти правила могут быть очень сложными с точки зрения числа полей, используемых для принятия решения, а спектр решений может быть широким. Кроме того, вполне возможно применение нескольких правил к одному профилю запроса. Например, политика может предписывать определенную обработку запросов от общей группы пользователей (например, сотрудники компании), а также иную обработку запросов другой группы (например, управляющих). В этом примере профиль managers соответствует двум правилам, одно из которых является общим, другое — более конкретным.

Чтобы справиться со сложностями принятия решений и обеспечить согласованность политики в рамках сети, язык описания правил должен обеспечивать однозначное сопоставления профиля запроса с действием политики. Язык также должен позволять упорядочение правил или указание приоритета для каждого правила. Некоторые из этих вопросов рассмотрены в [6].

 ________________                        ____________________
|                |                      |                    |
|    Узел сети   |  Сервер политики     |     Узел сети      |
|    _____       |      _____           |  _____      _____  |
|   |     |      |     |     |          | |     |    |     | |
|   | PEP |<-----|---->| PDP |          | | PEP |<-->| PDP | |
|   |_____|      |     |_____|          | |_____|    |_____| |
|    ^           |                      |                    |
|    |    _____  |                      |____________________|
|    \-->|     | |
|        | LPDP| |
|        |_____| |
|                |
|________________|

Рисунок 2. Два других варианта конфигурации компонент политики управления доступом. Слева показана локальная точка принятия решений на узле сети, а справа — PEP и PDP на одном узле.

В некоторых случаях простой конфигурации, показанной на рисунке 1, может оказаться недостаточно, поскольку нужно применять локальные правила (например, списки доступа) в дополнение к правилам удаленной точки PDP. Кроме того, PDP может размещаться на одном узле с PEP. Эти варианты показаны на рисунке 2.

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

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

Если не указано иное, в оставшейся части документа будет применяться конфигурация, показанная слева на рисунке 2.

В этой модели управления политикой модуль PEP на узле сети должен для принятия решения использовать указанные ниже действия.

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

2. PEP может обратиться к локальной базе конфигурации для идентификации набора элементов политики (назовем его A), которые могут быть проверены локально. Локальная конфигурация задает типы элементов политики для локальной оценки. PEP передает запрос с набором A локальной точке принятия решений LPDP и принимает результат LPDP («частичное решение», обозначенное D(A)).

3. Затем PEP передает запрос со всеми элементами политики и D(A) точке PDP, которая применяет правила ко всем элементам политики и запроса, принимая решение (обозначено D(Q)). Затем это решение объединяется с частичным решением D(A) для получения окончательного решения.

4. PDP возвращает окончательное решение (полученное при объединении) точке PEP.

Отметим, что в приведенной выше модели точка PEP должна контактировать с PDP даже при отсутствии (или NULL) объектов политики, полученных в запросе контроля доступа. Это требование помогает гарантировать для каждого запроса невозможность обойти управление политикой путем пропуска элементов политики в запросе на резервирование. Однако разрешено «короткое замыкание» при обработке, т. е. при отрицательном результате D(A) не требуется выполнять дополнительную проверку в PDP. Тем не менее, нужно информировать PDP об отказе при локальной обработке политики. То же самое относится к случаю, когда обработка политики прошла, но контроль доступа (на уровне управления ресурсом в результате нехватки емкости) дал отрицательный результат. PDP в этом случае также нужно информировать об отказе.

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

4.1. Пример маршрутизатора RSVP

Для маршрутизатора RSVP на рисунке 3 показано взаимодействие между PEP и другими компонентами int-serv в маршрутизаторе. Для обсуждения все компоненты, относящиеся к связанной с RSVP обработке, показаны в виде одного модуля RSVP, а более подробное обсуждение взаимодействия и интерфейсов между RSVP и PEP дано в [3].

   ______________________________
  |                              |
  |       Маршрутизатор          |
  |  ________           _____    |            _____
  | |        |         |     |   |           |     |
  | |  RSVP  |<------->| PEP |<--|---------->| PDP |
  | |________|         |_____|   |           |_____|
  |      ^                       |
  |      |      Контроль трафика |
  |      |      _____________    |
  |      \---->|  _________  |   |PC - классификатор
  |            | | емкость | |   |     пакетов
  |            | | ADM CTL | |   |PS - планировщик
  |            | |_________| |   |     пакетов
--|----------->|  ____ ____  |   |
  |   Данные   | | PC | PS | |   |
  |            | |____|____| |   |
  |            |_____________|   |
  |                              |
  |______________________________|

Рисунок 3. Связь между PEP и другими компонентами int-serv в маршрутизаторе RSVP

Когда сообщение RSVP приходит маршрутизатору (или связанное с RSVP событие требует решения политики), предполагается, что модуль RSVP передаст запрос (соответствующий событию или сообщению) модулю PEP, который будет использовать PDP (и LPDP) для принятия решения и возврата его модулю RSVP.

4.2. Дополнительная функциональность PDP

Обычно PDP возвращает окончательное решение на основе запроса управления доступом и связанных элементов политики. Однако у PDP должна быть возможность запросить PEP (или модуль контроля доступа в элементе сети, где размещается PEP) генерацию связанных с политикой сообщений об ошибках. Например, в случае RSVP точка PDP может воспринять запрос и разрешить организацию и пересылку резервирования предыдущему интервалу (hop), но в то же время сгенерировать сообщение об ошибке (предупреждение) нисходящему узлу (NHOP) для информирования о том, что «запрос может быть отменен по истечении 10 минут и т. п.». По сути нужна возможность создавать связанные с политикой сообщения об ошибках и/или предупреждения и распространять их с использованием естественного протокола сигнализации QoS (такого как RSVP). Такие ошибки, возвращаемые PDP, должны также обеспечивать возможность указать, следует ли по-прежнему воспринимать, устанавливать и пересылать запросы резервирования для продолжения обычной обработки RSVP. В частности, возвращенная PDP ошибка указывает, что

1. сообщение, создавшее запрос контроля доступа, следует обработать как обычно, а сообщение об ошибке (или предупреждение) следует передать в другом направлении и включить в него объекты политики, указанные в сообщении об ошибке;

2. или указывает, что была возвращена ошибка, но сообщение RSVP не следует пересылать как обычно.

4.3. Взаимодействие PEP, LPDP и PDP на маршрутизаторе RSVP

Все детали обработки сообщений RSVP и связанных с ними взаимодействий между разными элементами в маршрутизаторе RSVP (PEP, LPDP) и PDP описаны в отдельных документах [3,8]. Ниже приведены несколько аспектов, связанных с рассматриваемой моделью.

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

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

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

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

4.4. Размещение элементов политики в сети

Обеспечивая разделение задач между LPDP и PDP, архитектура управления политикой позволяет поэтапное развертывание путем включения маршрутизаторов различной степени сложности в части управления политикой взаимодействовать с серверами политики. На рисунке 4 приведен пример набора узлов в трех административных доменах (AD), каждый из которых относится к своему сервис-провайдеру. Узлы A, B, C относятся к AD-1, обслуживаемому PDP PS-1, а D и E относятся к AD-2 и AD-3, соответственно. Узел E взаимодействует с PDP PS-2. В общем случае предполагается наличие хотя бы одной точки PDP в каждом административном домене.

                        AD-1                    AD-2         AD-3
      ________________/\_______________     __/\___      __/\___
     {                                 }   {       }    {       }
             A           B            C            D            E
        +-------+  +-----+    +-------+    +-------+    +-------+
        | RSVP  |  | RSVP|    | RSVP  |    | RSVP  |    | RSVP  |
+----+  |-------|  |-----|    |-------|    |-------|    |-------|
| S1 |--| P | L |--|     |----| P | L |----| P | P |----|   P   | +----+
+----+  | E | D |  +-----+    | E | D |    | E | D |    |   E   |-| R1 |
        | P | P |             | P | P |    | P | P |    |   P   | +----+
        +-------+             +-------+    +-------+    +-------+
           ^                        ^                           ^
           |                        |                           |
           |                        |                           |
           |                        |                       +-------+
           |                        |                       | PDP   |
           |         +------+       |                       |-------|
           +-------->| PDP  |<------+                       |       |
                     |------|                               +-------+
                     |      |                                  PS-2
                     +------+
                       PS-1

Рисунок 4. Размещение элементов политики в сети.

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

5. Примеры политики, сценариев и поддержки политики

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

5.1. Правила восприятия на основе времени, отождествления и свидетельств

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

5.2. Двухсторонние соглашения между сервис-провайдерами

До недавнего времени соглашения между сервис-провайдерами для трафика через границу доменов были достаточно простыми. Например, два ISP могли согласовать восприятие любого трафика друг от друга без учета и оплаты пропускания «чужого» трафика. Однако доступность механизмов QoS, основанных на интеграции и дифференциации услуг, дифференциация трафика и гарантий качества обслуживания, привела к их постепенному внедрению в Internet. По мере того, как ISP начинают продавать своим пользователям различные уровни обслуживания и могут различать разные виды трафика, они будут искать механизмы оплаты друг другу трафика (и резервирования) через свои сети. Еще одним стимулом для создания таких механизмов является асимметрия трафика в терминах клиентской базы разных провайдеров. ISP, ориентированные на корпоративных заказчиков, скорей всего будут иметь более высокий спрос на резервирование по сравнению с провайдерами, обслуживающими индивидуальных пользователей. Отсутствие изощренных схем учета трафика между ISP может привести к неэффективному распределению затрат между разными сервис-провайдерами.

Двухсторонние соглашения можно разделить на две большие категории — локальные и глобальные. Сложность проблемы вынуждает предположить, что сначала будут применяться лишь первые. В них провайдеры, управляющие сетевым облаком или административным доменом, будут заключать договор со своим ближайшим соседом для задания основных правил и механизмов контроля доступа и учета. Эти договоры будут в основном локальными и не будут опираться на глобальные соглашения, поэтому узлы политики будут поддерживать лишь информацию о соседях. Применительно к рисунку 4, это подразумевает, что провайдер AD-1 будет иметь соглашение об использовании сети с AD-2, но не с AD-3. Провайдер AD-2 будет иметь соглашение с AD-3 и т. д. Таким образом, при пересылке запроса на резервирование в AD-2 провайдер AD-2 будет взимать плату с AD-1 за использование ресурсов вне сети AD-1. Эта информация получается путем рекурсивного применения двухсторонних соглашений на каждой границе между доменами (соседями), пока не дойдет до конечного получателя резервирования. Для реализации такой схемы в архитектуре управления политикой граничные узлы должны добавлять соответствующий объект политики в сообщение RSVP перед его пересылкой в сеть соседнего провайдера. Этот объект будет включать информацию о создавшем его провайдере и эквивалент учетного номера, по которому будут собираться данные для оплаты услуг. Поскольку соглашения существуют лишь между соседями, объекты политики должны заменяться в сообщениях RSVP при пересечении границы административного домена или сети провайдера.

5.3. Правила контроля доступа на основе приоритета

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

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

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

Из трех означенных выше требований слияние данных о приоритете является наиболее сложной задачей и заслуживает дополнительного обсуждения. Сложность слияния данных о приоритете обусловлена тем, что это объединение выполняется в дополнение к слиянию информации о резервировании. Когда данные о резервировании (FLOWSPEC) идентичны (резервирование однородно), при слиянии достаточно рассмотреть информацию о приоритете и простое правило сохранения высшего приоритета дает адекватный ответ. Однако при неоднородном резервировании, «двумерная природа» пар (FLOWSPEC, priority) усложняет их упорядочение и слияние. Описание обработки различных объектов RSVP с приоритетами представлено в работе [7].

5.4. Карты предоплаты и маркеры

В телефонных сетях набирает популярность модель на основе карт с предоплатой. Эта концепция применима и в Internet — пользователи покупают «маркеры», которые могут применяться для доступа к сетевым услугам. Когда пользователь запрашивает резервирование, передавая, например, сообщение RSVP RESV, он представляет уникальный идентификационных маркер, встроенный в объект политики. Обработка такого маркера на поддерживающем политику маршрутизаторе приводит к снижению числа «единиц обслуживания» для этого маркера.

Возвращаясь к рисунку 4, предположим, что получатель R1 в административном домене AD3 хочет зарезервировать услугу из AD1. R1 генерирует объект данных политики типа PD(prc, CID), где prc означает карту предоплаты, а CID указывает номер карты. Вместе с другими объектами политики в сообщении RESV этот объект приходит на узел E, который пересылает его своей точке PEP (PEP_E), а так обращается к PDP PS-3. Точка PS-3 обращается к локальной или удаленной карт предоплаты. Если кредит карты с номером CID не исчерпан, PDP разрешает резервирование и объект политики возвращается PEP_E. Здесь нужно решить два вопроса:

• какова область действия оплаты?

• когда оплата происходит в первый раз (в форме снижения остатка)?

Ответ на первый вопрос связан с действующими двухсторонними соглашениями. Если провайдер AD-3 имеет соглашения с AD-2 и AD-1, он будет оплачивать стоимость полного резервирования вплоть до отправителя S1. В этом случае PS-2 удалит объект PD(prc,CID) из отправляемого сообщения RESV.

Если же у AD-3 нет двухсторонних соглашений, он просто будет снимать с CID плату за резервирование внутри AD-3 и пересылать PD(prc,CID) в исходящем сообщении RESV. Следующие PDP в других административных доменах также снимут с CID плату за свое резервирование. Поскольку множество объектов считывает (оставшиеся средства) и записывает (снятие оплаты) информацию в одну базу данных, требуется тот или иной контроль доступа к базе и блокировка записи. Вопросы, связанные с размещением, поддержкой и координацией платежных баз данных выходят за рамки этого документа.

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

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

5.5. Заданные отправителем ограничения на резервирование

Возможность задания отправителем ограничений на резервирование с учетом отождествления получателя, числа получателей или стоимости резервирования может быть полезна в будущих сетевых приложениях. Примером может служит любое приложение, в котором отправитель платит за предоставление услуги получателям. В таких случаях отправитель может быть готов взять на себя оплату резервирования при выполнении некоторых условий, например, наличия получателя в списке доступа (ACL⁴) и соответствия некому пределу расходов (отметим, что это позволяет создавать «закрытые» multicast-группы).

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

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

6. Взаимодействие между PEP и PDP

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

6.1. Требования к протоколу между PEP и PDP

В этом разделе приведены общие требования к протоколу взаимодействия между PEP и внешней точкой PDP.

Надежность

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

Малые задержки

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

Способность передавать неразобранные объекты

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

Поддержка инициируемых PEP двухсторонних транзакций

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

Поддержка асинхронных уведомлений

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

Обслуживание multicast-групп

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

Спецификация QoS

Протоколу следует разрешать точное задание уровня требований к сервису. В запросах PEP, пересылаемых PDP.

7. Вопросы безопасности

Коммуникационный туннель между сервером и клиентом политики следует защищать с помощью IPSEC [4]. рекомендуется применять для таких туннелей оба протокола AH⁵ и ESP⁶, чтобы обеспечить конфиденциальность, целостность, аутентификацию источника данных и защиту от повторного использования пакетов.

В случае сигнализации RSVP может применяться аутентификация сообщений RSVP MD5 [2] для защиты коммуникаций между элементами сети.

8. Литература

[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

[2] Baker, F., Lindell, B. and M. Talwar, «RSVP Cryptographic Authentication», RFC 2747, January 2000.

[3] Herzog, S., «RSVP Extensions for Policy Control», RFC 2750, January 2000.

[4] Atkinson, R., «Security Architecture for the Internet Protocol», RFC 1825⁷, August 1995.

[5] Rigney, C., Rubens, A., Simpson, W. and S. Willens, «Remote Authentication Dial In User Service (RADIUS)», RFC 2138⁸, April 1997.

[6] Rajan, R., et al., «Schema for Differentiated Services and Integrated Services in Networks», Work in Progress.

[7] Herzog, S., «RSVP Preemption Priority Policy», Work in Progress.

[8] Herzog, S., «COPS Usage for RSVP», RFC 2749, January 2000.

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

Эта работа является результатом обсуждений среди членов группы RAP, включая Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, Shai Herzog, Tim O’Malley, Raju Rajan и Arun Sastry.

10. Адреса авторов

Raj Yavatkar

Intel Corporation

2111 N.E. 25th Avenue,

Hillsboro, OR 97124

USA

Phone: +1 503-264-9077

EMail: raj.yavatkar@intel.com

Dimitrios Pendarakis

IBM T.J. Watson Research Center

P.O. Box 704

Yorktown Heights

NY 10598

Phone: +1 914-784-7536

EMail: dimitris@watson.ibm.com

Roch Guerin

University of Pennsylvania

Dept. of Electrical Engineering

200 South 33rd Street

Philadelphia, PA 19104

Phone: +1 215 898-9351

EMail: guerin@ee.upenn.edu

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

11. Полное заявление авторских прав

Copyright (C) The Internet Society (2000). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

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

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

Network Working Group                                F. Baker
Request for Comments: 2747                              Cisco
Category: Standards Track                          B. Lindell
                                                      USC/ISI
                                                    M. Talwar
                                                    Microsoft
                                                 January 2000

Криптографическая аутентификация RSVP

RSVP Cryptographic Authentication

PDF

Статус документа

Этот документ содержит проект стандартного протокола для сообщества Internet и служит запросом для обсуждения в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (2000). All Rights Reserved.

Аннотация

В этом документе описан формат и применение объекта RSVP INTEGRITY для поэтапного обеспечения целостности и аутентификации сообщений RSVP.

1. Введение

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

Для обеспечения защиты целостности этого механизма контроля доступа от протокола RSVP требуется способность защитить сообщения от подмены и повреждения. В этом документе определен механизм поэтапной защиты целостности сообщений RSVP. В предложенной схеме передается аутентификационная подпись сообщения, которая создается с использованием секрета Authentication Key и алгоритма хэширования с ключами. Схема обеспечивает защиту от подмены или изменения сообщений. Объект INTEGRITY в каждом сообщении RSVP помечается порядковым номером одноразового использования. Это позволяет получателю идентифицировать повторно используемые сообщения и, следовательно, предотвратить атаки, основанные на повторном использовании (replay) сообщений. Предложенный механизм не обеспечивает защиты конфиденциальности, поскольку сообщения не шифруются. Однако следует помнить, что этот механизм может использоваться при международном обмене данными, а в разных странах могут применяться различные требования к шифрованию данных и экспорту шифров.

Примечание. В этом документе смысл терминов «отправитель» (sender) и «получатель» (receiver) отличается от принятого в [1]. Термины относятся к системам, расположенным по разные стороны одного интервала (hop) RSVP, при этом отправителем считается система, генерирующая сообщения RSVP.

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

Предложенный механизм не зависит от какого-либо криптографического алгоритма, но в документе описывается применение хеширования с ключами для аутентификации сообщений² с использованием HMAC-MD5 [7]. Как отмечено в работе [7], существуют более строгие алгоритмы хэширования (типа HMAC-SHA1); с тех случаях, где это целесообразно, реализациям следует делать такие алгоритмы доступными. Однако для общего случая в документе [7] показана адекватность HMAC-MD5 для заявленной цели, а также отмечено преимущество этого алгоритма в части производительности. В работе [7] также приведен исходный код и тестовые векторы для данного алгоритма, позволяющие проверить интероперабельность. HMAC-MD5 требуется в качестве базового механизма RSVP для обеспечения криптографической аутентификации, но опционально могут быть предложены и другие алгоритмы (см. раздел 6).

Контрольные суммы RSVP могут быть отключены (0) wпри включении в сообщение объекта INTEGRITY, поскольку цифровая подпись обеспечивает более строгую проверку целостности, нежели контрольная сумма.

1.1. Используемые соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [8].

1.2. Почему не применяется стандартный заголовок IPSEC AH?

Возникает вопрос, почему при наличии стандартного механизма аутентификации IPSEC [3,5] предлагается применять иной механизм. Этот вопрос долго обсуждался в рабочей группе и от применения IPSEC отказались по описанным ниже причинам.

Защищенные связи в IPSEC базируются на адресах получателей. Не очевидно, что сообщения могут быть надежно определены для любого отправителя или получателя на базе защищенных связей, поскольку маршрутизаторы должны пересылать сообщения PATH и PATH TEAR с использованием того же адреса отправителя, который отправитель указал в SENDER TEMPLATE. Иначе служебный трафик RSVP может пойти по пути, отличному от пути доставки данных. Использование связей на основе адреса получателя или отправителя будет требовать создания новых защищенных связей между маршрутизаторами, через которые организуется резервирование.

Кроме того, отмечено, что отношения соседства между системами RSVP не ограничиваются простой смежностью на одном коммуникационном канале. Отношения RSVP могут организовываться через облака, не поддерживающие RSVP (определены в параграфе 2.9 работы [1]), которые могут быть невидимыми для передающей системы. На основании этих аргументов предложена стратегия управления ключами на базе парных связей между маршрутизаторами RSVP взамен применения IPSEC.

2. Структуры данных

2.1. Формат объекта INTEGRITY

Сообщение RSVP состоит из последовательности «объектов» представляющих собой структуры вида TLV³. Информация, требуемая для поэтапной (hop-by-hop) проверки целостности, передается в объектах INTEGRITY. Одинаковые объекты INTEGRITY применимы как для IPv4, так и для IPv6.

Формат объекта INTEGRITY показан ниже.

       INTEGRITY: Class = 4, C-Type = 1

       +-------------+-------------+-------------+-------------+
       |    Flags    | 0 (резерв)  |                           |
       +-------------+-------------+                           +
       |                    Key Identifier                     |
       +-------------+-------------+-------------+-------------+
       |                    Sequence Number                    |
       |                                                       |
       +-------------+-------------+-------------+-------------+
       |                                                       |
       +                                                       +
       |                                                       |
       +                  Keyed Message Digest                 |
       |                                                       |
       +                                                       +
       |                                                       |
       +-------------+-------------+-------------+-------------+
Flags - 8-битовое поле, формат которого показан ниже.
                                      Flags

                          0   1   2   3   4   5   6   7
                        +---+---+---+---+---+---+---+---+
                        | H |                           |
                        | F |             0             |
                        +---+---+---+---+---+---+---+---+

В настоящее время определен лишь флаг HF, а оставшиеся биты являются резервными и должны иметь значение 0.

• Бит 0 — флаг согласования HF⁴ относится к согласованию механизма контроля целостности (параграф 4.3). Отправителям сообщений, желающим отвечать на сообщения согласования защиты целостности, следует устанавливать для флага значение 1, а отвергающим такое согласование следует устанавливать 0.

• Key Identifier — 48-битовое целое число без знака, которое должно быть уникальным для данного отправителя. Уникальные в локальном масштабе значения Key Identifier можно создавать на основе адресов (IP, MAC или LIH) передающего интерфейса и номера ключа. Комбинация Key Identifier с IP-адресом системы является уникальным идентификатором защищенной связи (параграф 2.2).

• Sequence Number — 64-битовый, монотонно возрастающий порядковый номер (целое число без знака).

  В качестве значений Sequence Number могут служить монотонно возрастающие последовательности из объектов INTEGRITY [каждого сообщения RSVP] с тегом, обеспечивающим уникальную связь с временем жизни ключа. Генерация порядковых номеров подробно рассматривается в разделе 3.

• Keyed Message Digest — подпись должна иметь размер, кратный 4 октетам. Для HMAC-MD5 размер подписи составляет 16 байтов.

2.2. Защищенная связь

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

• алгоритм аутентификации и используемый режим этого алгоритма;

• ключ, применяемый с алгоритмом аутентификации;

• время жизни ключа;

• привязанный передающий интерфейс и другие критерии выбора защищенной связи [требуется на передающей системе];

• адрес отправителя на передающей системе [требуется на приемной системе];

• последний переданный порядковый номер, использованный с этим идентификатором ключа [требуется на приемной системе];

• список из последних N порядковых номеров, принятых с этим идентификатором ключа [требуется на приемной системе].

3. Генерация порядковых номеров

В этом параграфе описаны методы, которые могут быть выбраны для генерации порядковых номеров, используемых в объектах INTEGRITY сообщений RSVP. Как было отмечено выше, имеются два важных свойства, которые должны быть обеспечены в процедуре генерации. Первым свойством является уникальность (однократное применение) порядковых номеров в течение всего срока жизни текущего используемого ключа защиты целостности. Получатель может использовать это свойство для того, чтобы однозначно различать новые и повторные сообщения. Вторым свойством является монотонный рост номеров с использованием модуля 2⁶⁴. Это требуется для существенного снижения сохраняемого объема состояний, поскольку получателю достаточно сохранить значение с наибольшим порядковым номером для предотвращения атак с повторным использованием пакетов (replay). Поскольку начальный порядковый номер может быть произвольно большим, требуется применение операций с модулем для обеспечения возможности начала отсчета с нуля в течение жизни одного ключа. Это решение основано на нумерации в TCP [9].

Поле порядкового номера трактуется, как 64-битовое целое число без знака. Размер поля достаточно велик для того, чтобы нумерации хватило на весь срок жизни ключа. Например, если для ключа выбран срок жизни в 1 год, нумерации будет достаточно для передачи сообщений RSVP со средней скоростью около 585 Гига-сообщений в секунду. Использование 32-битовых порядковых номеров снизило бы этот предел до 136 сообщений в секунду.

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

3.1. Простые порядковые номера

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

3.2. Порядковые номера на основе системного времени

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

В этой модели можно использовать основанную на NTP временную метку в качестве порядкового номера. Цикл полного отсчета для временных меток NTP составляет около 136 лет, что значительно превышает разумный срок жизни любого ключа. Кроме того, дискретность меток NTP достаточно хороша для того, чтобы можно было генерировать сообщение RSVP для данного ключа каждые 200 пикосекунд. Однако многие часы не поддерживают уровня дискретности меток NTP. В таких случаях младшие биты временной метки можно создавать с использованием счетчика сообщений, который сбрасывается при каждом «тике» системных часов. Например, если часы обеспечивают дискретность в 1 секунду, 32 младших бита порядкового номера можно задавать с использованием счетчика сообщений. В оставшиеся 32 бита порядкового номера следует помещать 32 старших⁵ бита временной метки. Если предположить, что время восстановления после отказа занимает более одного «тика» системных часов, значение счетчика для младших битов порядкового номера можно смело сбрасывать после перезапуска системы.

3.3. Порядковые номера на основе сетевого времени

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

4. Обработка сообщений

Реализациям следует разрешать спецификацию интерфейсов, которые будут защищены для отправки сообщений, их приема или в обоих случаях. Отправитель должен обеспечить во всех сообщениях RSVP, передаваемых через защищенные интерфейсы, наличие объекта INTEGRITY, созданного с использованием подходящего ключа Key. Получатели проверяют сообщения RSVP (за исключением типа Integrity Challenge, см. параграф 4.3), прибывающие на защищенный приемный интерфейс, на предмет наличия в них объекта INTEGRITY. Если объект INTEGRITY отсутствует, получатель отбрасывает сообщение.

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

Каждому отправителю следует иметь разные защищенные связи (и ключи) на защищенных передающих интерфейсах (или LIH). Хотя администраторы могут настроить все маршрутизаторы и хосты своей подсети (или сети) на использование одной защищенной связи, реализации должны предполагать, что каждый отправитель может передавать, используя отдельную защищенную связь на каждом защищенном интерфейсе. На стороне отправителя выбор защищенной связи происходит по интерфейсам, через которые передается сообщение. Этот выбор может учитывать дополнительные критерии типа адреса получателя (при передаче unicast-сообщения через широковещательную ЛВС с большим числом хостов) или идентификации пользователя на стороне отправителя или получателя [2]. Кроме того, все предполагаемые получатели сообщения должны участвовать в этой защищенной связи. Переключения (flap) маршрутов в сети без поддержки RSVP могут приводить к передаче сообщений для одного получателя через разные интерфейсы в разное время. В таких случаях получателю следует участвовать во всех защищенных связях, которые могут быть выбраны для возможных выходных интерфейсов.

Получатели выбирают ключи на основе Key Identifier и IP-адреса передающей стороны. Значение Key Identifier включается в объект INTEGRITY. Адрес передающей стороны может быть получен из объекта RSVP_HOP или (при отсутствии такого объекта, как в случае сообщений PathErr и ResvConf) из IP-адреса отправителя. Поскольку значение Key Identifier уникально для отправителя, этот метод обеспечивает уникальную идентификацию ключа.

Механизм защиты целостности слегка меняет правила обработки сообщений RSVP при включении объектов INTEGRITY в сообщения, передаваемые через защищенный интерфейс и при восприятии сообщений, принятых через защищенный интерфейс. Эти изменения подробно рассмотрены ниже.

4.1. Генерация сообщений

Сообщения RSVP, передаваемые через защищенный выходной интерфейс, создаются, как описано в [1], за исключением перечисленного ниже.

1. Поле контрольной суммы RSVP устанавливается в 0. При необходимости контрольная сумма RSVP может быть рассчитана по завершении обработки объекта INTEGRITY.

2. Объект INTEGRITY помещается в подходящее место и его позиция в сообщении запоминается для последующего использования.

3. Передающий интерфейс и другие подходящие критерии (как указано выше) используются для определения ключа аутентификации Authentication Key и применяемого алгоритма хэширования.

4. Неиспользуемые флаги и резервные поля объекта INTEGRITY должны быть установлены в 0. Флаг согласования HF⁶ следует устанавливать в соответствии с правилами, описанными в параграфе 2.1.

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

6. В поле Keyed Message Digest помещается значение 0.

7. Идентификатор ключа (Key Identifier) включается в объект INTEGRITY.

8. Рассчитывается аутентификационная подпись сообщения с использованием Authentication Key в комбинации с алгоритмом хеширования. Для случая алгоритма HMAC-MD5 вычисление хэш-значения описано в [7].

9. Полученная подпись записывается в поле Cryptographic Digest объекта INTEGRITY.

4.2. Прием сообщений

Когда сообщение принимается на защищенном входном интерфейсе и не относится к типу Integrity Challenge, выполняются следующие операции:

1. Значение поля контрольной суммы RSVP сохраняется, а в поле помещается 0.

2. Значение поля Cryptographic Digest объекта INTEGRITY сохраняется, а в поле помещается 0.

3. Поле Key Identifier и адрес передающей системы служат для однозначного (уникального) определения Authentication Key и используемого алгоритма хэширования. Обработка этого пакета может быть задержана , если данная информация запрашивается в системе управления ключами (Приложение 1).

4. Рассчитывается новая подпись с использованием указанного алгоритма и ключа Authentication Key.

5. Если рассчитанная подпись не совпадает с полученной, сообщение отбрасывается без дальнейшей обработки.

6. Если сообщение относится к типу Integrity Response, проверяется соответствие объекта CHALLENGE запросу. При наличии соответствия порядковый номер сохраняется в объекте INTEGRITY, как наибольший принятый номер.

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

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

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

При получении на защищенном интерфейсе сообщения Integrity Challenge оно обрабатывается следующим образом:

1. Формируется сообщение Integrity Response с использованием объекта Challenge, полученного в сообщении-вызове.

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

4.3. Согласование защиты целостности при перезапуске и инициализации получателя

Чтобы получить стартовый порядковый номер для Authentication Key, получатель может инициировать согласование защиты целостности с отправителем. Это согласование включает вызов получателя Challenge и отклик отправителя Response, согласование может быть инициировано в процессе перезапуска или отложено до момента приема сообщения, подписанного ключом.

Когда получатель решил инициировать согласование защиты целостности для конкретного ключа Authentication Key, он идентифицирует отправителя с использованием адреса передающей системы, настроенного для соответствующей защищенной связи. Получатель передает сообщение RSVP Integrity Challenge отправителю. Это сообщение содержит Key Identifier для идентификации ключа отправителя и должно иметь уникальной значение cookie отправителя, основанное на локальном секрете для предотвращения его подбора (см. параграф 2.5.3 работы [4]). Предполагается, что значение cookie будет представлять собой хэш MD5 для локального секрета и временной метки с целью обеспечения уникальности (см. раздел 9).

Сообщение RSVP Integrity Challenge относится к типу 11 и имеет формат:

<Integrity Challenge> ::= <Common Header> <CHALLENGE>

Объект CHALLENGE имеет формат:

       CHALLENGE: Class = 64, C-Type = 1

       +-------------+-------------+-------------+-------------+
       |         0 (резерв)        |                           |
       +-------------+-------------+                           +
       |                    Key Identifier                     |
       +-------------+-------------+-------------+-------------+
       |                    Challenge Cookie                   |
       |                                                       |
       +-------------+-------------+-------------+-------------+

Отправитель воспринимает Integrity Challenge без проверки целостности. Он возвращает сообщение RSVP Integrity Response, содержащее исходный объект CHALLENGE. Сообщение также включает объект INTEGRITY, подписанный с помощью ключа, заданного Key Identifier из Integrity Challenge.

Сообщение RSVP Integrity Response относится к типу 12 и имеет формат:

<Integrity Response> ::= <Common Header> <INTEGRITY> <CHALLENGE>

Сообщение Integrity Response воспринимается получателем (challenger) только в том случае, когда оно возвращает объект CHALLENGE, соответствующий переданному в сообщении Integrity Challenge. Это предотвращает повторное использование старых сообщений Integrity Response. Если объекты соответствуют, получатель сохраняет номер Sequence Number из объекта INTEGRITY в качестве последнего номера, полученного с идентификатором ключа, включенным в объект CHALLENGE.

Если отклик не приходит в течение заданного периода, запрос (challenge) повторяется. После успешного завершения процедуры согласования защиты целостности получатель начинает воспринимать обычные сигнальные сообщения RSVP от данного отправителя и игнорирует другие сообщения Integrity Response.

Флаг согласования HF (Handshake Flag) используется для того, чтобы обеспечить реализациям гибкость без использования механизма согласования защиты целостности. Путем установки этого флага (1) отправители сообщений, реализующие согласование защиты целостности, отличают себя от остальных. Получателям не следует пытаться согласовывать защиту целостности с отправителями, чьи объекты INTEGRITY имеют HF = 0.

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

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

5. Управление ключами

Вполне вероятно, что IETF будет определять стандартный протокол управления ключами. Весьма желательно использовать этот протокол для распространения ключей RSVP Authentication Key между взаимодействующими реализациями RSVP. Такой протокол обеспечит масштабируемость и существенное снижение нагрузки на администраторов. Идентификаторы ключей (Key Identifier) могут послужить связкой между RSVP и будущим протоколом управления ключами. Протоколы управления ключами имеют долгую историю недостатков, которые зачастую обнаруживались значительно позже публикации соответствующего протокола. Чтобы избежать необходимости изменения всех реализаций RSVP в результате обнаружения таких недостатков, встроенные средства управления ключами были преднамеренно исключены из данной спецификации.

5.1. Процедуры управления ключами

Каждый ключ имеет связанное с ним время жизни, которое записывается во всех системах (отправители и получатели), настроенных на работу с этим ключом. Концепция «времени жизни» ключа требует лишь понятного для систем представления значения начала (KeyStartValid) и завершения (KeyEndValid) срока действия ключа. Некоторые механизмы генерации ключей типа Kerberos и некоторых схем с открытыми ключами, могут напрямую создавать эфемерные ключи. В таких случаях время жизни ключа неявно определяется самим ключом.

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

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

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

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

5.2. Требования к управлению ключами

Требования к реализациям перечислены ниже.

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

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

• Реализации должны связывать конкретное время жизни (KeyStartValid и KeyEndValid) с каждым ключом и соответствующим идентификатором Key Identifier.

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

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

• Устаревшие ключи могут автоматически удаляться реализацией.

• Должно также поддерживаться удаление активных ключей вручную.

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

5.3. Патологический случай

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

6. Требования по соответствию

Для соответствия данной спецификации реализация должна поддерживать все аспекты спецификации. Во всех соответствующих этому документу реализациях должен поддерживаться алгоритм аутентификации HMAC-MD5, определенный в [7]. В соответствии со спецификацией реализации могут также поддерживать другие алгоритмы аутентификации типа NIST Secure Hash Algorithm (SHA). Все реализации должны поддерживать описанное выше распространение ключей вручную. Все реализации должны поддерживать продление срока жизни ключей, как описано в параграфе «5.1. Процедуры управления ключами».

Реализациям следует поддерживать стандартный протокол управления ключами для защищенного распространения ключей RSVP Authentication Key после того, как такой протокол будет стандартизован IETF.

7. Генерация Authentication Key с помощью Kerberos

Алгоритм Kerberos[10] может использоваться для генерации ключей RSVP Authentication, применяемых для генерации подписи в объектах Integrity, которые передаются отправителем RSVP получателям. Генерация ключей Kerberos избавляет от необходимости применения ключей, разделяемых отправителями и получателями RSVP (хосты и маршрутизаторы). Kerberos позволяет использовать связь между защищаемыми сторонами (отправитель и получатели RSVP) через доверенную третью сторону, когда центр распространения ключей Kerberos (KDC) организует эфемерные сеансовые ключи впоследствии разделяемые между отправителем и получателями RSVP. Для группового случая все получатели группового сообщения RSVP должны разделять общий ключ с KDC (т. е., получатели эффективно являются защищаемой стороной относительно Kerberos).

Информация о ключе (Key information), определенная отправителем, может задавать использование Kerberos вместо заданных в конфигурации разделяемых ключей в качестве механизма обмена ключами между отправителем и получателем. Kerberos-идентификация получателя организуется в процессе настройки конфигурации интерфейса отправителя или с помощью иного механизма. При генерации первого сообщения RSVP для конкретного идентификатора ключа отправитель запрашивает «квитанцию» от сервиса Kerberos и получет эфемерный сеансовый ключ и квитанцию Kerberos от KDC. Отправитель инкапсулирует квитанцию и свою идентификацию в объект Identity Policy [2]. Объект Policy Object отправитель включает в сообщение RSVP. Сеансовый ключ используется отправителем в качестве ключа RSVP Authentication на этапе (3) (параграф 4.1) и сохраняется как информация о ключе, связанная в идентификатором ключа.

При получении сообщения RSVP приемная сторона извлекает Kerberos Ticket из объекта Identity Policy, дешифрует квитанцию и извлекает из нее сеансовый ключ. Этот ключ совпадает с применяемым отправителем ключом и используется на этапе (3) (параграф 4.2). Получатель сохраняет ключ для использования при обработке последующих сообщений RSVP.

Квитанции Kerberos действительны в течение ограниченного времени и отправителю недопустимо использвать квитанции с истекшим временем жизни. Отправитель должен запросить и использовать новую квитанцию для получателя до завершения срока действия предыдущей.

7.1. Оптимизация при использовании аутентификации на базе Kerberos

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

У получателя может не оказаться кэшированного ключа с его Key Identifier по причине перезагрузки или изменения маршрута. Если политика получателя задает использование ключей Kerberos для проверки целостности, получатель может передать отправителю сообщение Integrity Challenge. При получении такого сообщения отправитель должен передать объект Identity, включающий квитанцию Kerberos, в сообщении Integrity Response, что позволит получателю получить и сохранить сеансовый ключ из квитанции Kerberos для последующих проверок целостности.

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

Этот документ непосредственно базируется на похожей работе, выполненной для протоколов OSPF и RIP Version II совместно Ran Atkinson и Fred Baker. Существенная работа по редактированию была выполнена Bob Braden, что улучшило ясность изложения. Были получены важные комментарии от Steve Bellovin, хорошо знающего эту тему. Matt Crawford и Dan Harkins помогли в пересмотре документа.

9. Литература

[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

[2] Yadav, S., et al., «Identity Representation for RSVP», RFC 2752⁸, January 2000.

[3] Atkinson, R. and S. Kent, «Security Architecture for the Internet Protocol», RFC 2401, November 1998.

[4] Maughan, D., Schertler, M., Schneider, M. and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 2408, November 1998.

[5] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402, November 1998.

[6] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, November 1998.

[7] Krawczyk, H., Bellare, M. and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, March 1996.

[8] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997. (перевод)

[9] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981. (перевод)

[10] Kohl, J. and C. Neuman, «The Kerberos Network Authentication Service (V5)», RFC 1510¹³, September 1993.

10. Вопросы безопасности

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

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

Целостность сообщений Integrity Response проверяется, но целостность Integrity Challenge не контролируется. Это сделано осознанно с целью предотвратить возникновение ситуаций, когда оба маршрутизатора-партнера не имеют начальный порядковых номеров для ключа другой стороны. В таком случае оба маршрутизатора продолжали бы передачу сообщений Integrity Challenge, которые другая стороны просто отбрасывала бы. Более того, проверка целостности только для одного типа сообщений избавляет от необходимости наличия защищенной связи в обратном направлении.

Однако это позволяет атакующему генерировать обманные запросы на согласование с неким challenge cookie. Атакующий может сохранить полученные отклики и попытаться использовать их для атаки на восстанавливаемого получателя. При определенном везении атакующий может угадать значение challenge cookie, используемые получателем в процессе восстановления. Тогда переданный атакующим обманный отклик будет воспринят, поскольку он имеет корректную подпись и меньший, чем у отправителя порядковый номер (поскольку сообщение будет более старым). Таким образом открывается возможность атаки на получателя с повторным использованием пакетов. Однако использование такой возможности представляется весьма проблематичным. Требуется не только заранее угадать значение challenge cookie (основано на локальном секрете), но и иметь возможность замаскироваться под получателя для генерации Integrity Challenge с корректным адресом IP и не оказаться пойманным.

Данный механизм не обеспечивает защиты конфиденциальности. Если такая защита нужна, эффективным решением может быть IPSEC ESP [6], хотя ему полностью присущи недостатки IPSEC Authentication и, следовательно, применение возможно только в специфических средах. Не обеспечивается и защиты от анализа трафика. Для обеспечения такой защиты могут применяться механизмы шифрования данных на уровне канала.

11. Адреса авторов

Fred Baker

Cisco Systems

519 Lado Drive

Santa Barbara, CA 93111

Phone: (408) 526-4257

EMail: fred@cisco.com

Bob Lindell

USC Information Sciences Institute

4676 Admiralty Way

Marina del Rey, CA 90292

Phone: (310) 822-1511

EMail: lindell@ISI.EDU

Mohit Talwar

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

Phone: +1 425 705 3131

EMail: mohitt@microsoft.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

12. Приложение 1 — Интерфейс управления ключами

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

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

12.1. Структура данных

Информация о ключах возвращается в структуре данных KeyInfo.

     KeyInfo {
             Тип ключа (Send или Receive)
             KeyIdentifier
             Ключ
             Тип и режим алгоритма аутентификации
             KeyStartValid
             KeyEndValid
             Статус (Active или Deleted)
             Выходной интерфейс (только для Send)
             Другие критерии выбора исходящей защищенной связи 
                     (только для Send, не обязательно)
             Адрес передающей системы (только для Receive)
     }

12.2. Таблица используемых по умолчанию ключей

Эта функция возвращает список структур KeyInfo, соответствующих всем ключам, которые указаны для передачи и приема сообщений RSVP и имеют активный статус (Active). Функция обычно вызывается на начальном этапе исполнения процесса, но число ее вызовов ничем не ограничено.

KM_DefaultKeyTable() -> KeyInfoList

12.3. Запрос неизвестных ключей приема

При получении сообщения с неизвестной парой (Key Identifier, Sending System Address) RSVP может использовать эту функцию для запроса подходящего ключа у системы управления ключами (Key Management System). Функция возвращает статус элемента (если он найден), который должен иметь значение Active.

KM_GetRecvKey( INTEGRITY Object, SrcAddress ) -> KeyInfo

12.4. Опрос на предмет обновлений

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

KM_KeyTablePoll() -> KeyInfoList

12.5. Интерфейс асинхронных Upcall-вызовов

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

KM_KeyUpdate( Function [, KeyIdentifier ] )

где upcall-функция параметризуется следующим образом:

Function( KeyInfo )

13. Полное заявление авторских прав

Copyright (C) The Internet Society (2000). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

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

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

Заменен RFC 3986

Network Working Group                                     D. Awduche
Request for Comments: 2702                                J. Malcolm
Category: Informational                                   J. Agogbua
                                                           M. O'Dell
                                                          J. McManus
                                                UUNET (MCI Worldcom)
                                                      September 1999

Требования к построению трафика в сетях MPLS

Requirements for Traffic Engineering Over MPLS

PDF

Статус документа

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

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

Аннотация

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

1.0 Введение

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

С помощью этой сравнительно простой парадигмы можно разработать набор мощных конструкций для решения множества вопросов в части дифференциации услуг Internet. Одним из наиболее значимых стартовых приложений MPLS будет построение трафика (TE²). Важность этого приложение уже достаточно очевидна (см. [1,2,3]).

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

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

Среди недавних работ по построению трафика и управлению трафиком в MPLS следует отметить работу Li и Rekhter [3], а также ряд других документов. В работе [3] предложена архитектура, которая использует MPLS и RSVP для развертывания масштабируемых систем с дифференциацией услуг, а также для построения трафика Internet. Этот документ служит дополнением к упомянутой работе. Здесь отражен опыт авторов в части управления крупными магистральными сетями Internet.

1.1 Терминология

Предполагается, что читатель знаком с терминологией MPLS, определенной в [1].

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [11].

1.2 Организация документа

Оставшаяся часть документа организована следующим образом — в разделе 2 рассматриваются базовые функции TE в Internet, в разделе 3 дан обзор возможностей MPLS в части построения трафика (разделы 1 — 3 являются базовыми для дальнейшего понимания), в разделе 4 дан обзор фундаментальных требований к построению трафика в MPLS, в разделе 5 описаны желаемые атрибуты и характеристики транков, относящиеся к TE, раздел 6 посвящен набору атрибутов, которые могут быть связаны с ресурсами для ограничения маршрутизируемости транков трафика и LSP через них, в разделе 7 рассматривается схема основанной на ограничениях маршрутизации³ в доменах MPLS, а раздел 8 содержит заключительные ремарки.

2.0 Построение трафика

В этом разделе рассмотрены базовые функции построения трафика в автономной системе (AS⁴) современной сети Internet. Отмечены ограничения современных протоколов IGP в части управления трафиком и ресурсами. Этот раздел служит мотивацией для разработки требований к MPLS.

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

Основной целью построения трафика Internet является достижение эффективной и надежной работы сети вкупе с оптимизацией использования сетевых ресурсов и высокой производительностью. TE становится необходимым для множества крупных AS, по причине высокой стоимости сетевых активов, а также коммерциализации и конкуренции в сети Internet. Эти факторы усиливают требование обеспечения максимальной операционной эффективности.

2.1 Цели TE

Ключевые цели повышения производительности, связанные с построением трафика, можно классифицировать, как:

1. ориентированные на трафик;
2. ориентированные на ресурсы.

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

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

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

1. сетевых ресурсов недостаточно или они не могут адекватно приспосабливаться к уровню трафика;
2. потоки трафика неэффективно отображаются на доступные ресурсы, что приводит к перегрузке части ресурсов и простою других.

Для первого случая проблему перегрузок можно решить (i) добавлением ресурсов, (ii) использованием классических механизмов контроля насыщения или (iii) комбинацией этих методов. Классические методы контроля насыщения пытаются урегулировать запросы таким образом, чтобы трафик «вписывался» в доступные ресурсы. Классические методы включают: ограничение скорости, управление окном потока данных, управление очередями в маршрутизаторах, управление на основе планирования, а также другие методы (см. документ [8] и ссылки в нем).

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

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

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

2.2 Управление трафиком и ресурсами

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

В идеальном случае управляющие воздействия должны включать:

1. изменение параметров управления трафиком;
2. изменение параметров, связанных с маршрутизацией;
3. изменение атрибутов и ограничений, связанных с ресурсами.

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

2.3 Ограничения современных механизмов управления IGP

В этом параграфе рассмотрены некоторые известные ограничения протоколов внутренней маршрутизации (IGP) в части построения трафика.

Возможностей управления, предлагаемых современными протоколами внутренней маршрутизации Internet, недостаточно для TE. Это осложняет реализацию эффективных правил для решения проблем сетевой производительности. Действительно, протоколы IGP, основанные на алгоритмах поиска кратчайшего пути, вносят существенный вклад в возникновение проблем перегрузки в автономных системах Internet. Алгоритмы SPF в общем случае оптимизируются на базе простой аддитивной метрики. Эти протоколы зависят от топологии и характеристики трафика не принимаются во внимание при решении вопросов о выборе маршрута. В результате этого перегрузка зачастую возникает, когда наблюдается любое из приведенных ниже условий:

1. кратчайшие пути для множества потоков трафика сводятся в конкретные каналы или интерфейсы маршрутизаторов;
2. данный поток трафика маршрутизируется через канал или интерфейс маршрутизатора, который не обеспечивает требуемой для потока полосы пропускания.

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

Популярным вариантом преодоления неадекватности современных IGP является использование модели с перекрытием типа IP over ATM или IP over Frame Relay. Модели с перекрытием расширяют возможности организации, разрешая использовать произвольные виртуальные топологии «поверх» топологии физической сети. Виртуальная топология строится из виртуальных устройств, которые выглядят физическими каналами с точки зрения протоколов маршрутизации IGP. Модели с перекрытием дополнительно обеспечивают важные типы сервиса для поддержки управления трафиком и ресурсами, включая: (1) маршрутизацию на базе ограничений⁶ на уровне VC, (2) поддержку административно настраиваемых явных путей VC, (3) компрессию путей, (4) функции управления вызовами, (5) функции формовки трафика, а также (6)выживаемость VC. Эти возможности позволяют реализовать различные правила TE. Например, для виртуальных устройств можно легко изменить маршрутизацию для перемещения трафика с перегруженных ресурсов на относительно свободные.

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

3.0 MPLS и построение трафика

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

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

Замечание по терминологии. В этом документе широко используется понятие транков трафика MPLS. В работе Li и Rekhter [3] транк трафика⁷ определен, как агрегат (объединение) потоков трафика одного класса, который может быть помещен в путь с коммутацией по меткам (LSP⁸). Важно отметить, что транк является абстрактным представлением трафика, с которым могут быть связаны конкретные характеристики. Полезно рассматривать транки, как объекты, которые могут маршрутизироваться (т. е., путь, через который проходит транк, может быть изменен). В этом смысле транки похожи на виртуальные устройства в сетях ATM и Frame Relay. Важно подчеркнуть, что между транками и путями LSP, через которые они проходят существует фундаментальное различие. LSP представляет собой спецификацию пути с коммутацией по меткам, через который проходит транк. На практике же термины LSP и транк трафика часто используются, как синонимы. Дополнительные характеристики транков, используемые в этом документе, приведены в параграфе 5.0.

Привлекательность MPLS для построения трафика можно объяснить несколькими факторами: (1) явные пути с коммутацией по меткам, не привязанные к получателям, как в традиционной парадигме пересылки, легко можно создавать путем административных действий вручную или автоматически с помощью протоколов нижележащих уровней, (2) LSP можно управлять достаточно эффективно, (3) транки трафика можно создавать и отображать на LSP, (4) с транком трафика можно связать набор атрибутов, который позволит изменить характеристики поведения транка, (5) с ресурсами можно связать наборы атрибутов, которые будут ограничивать размещение LSP и транков трафика с использованием этих ресурсов, (6) MPLS разрешает агрегирование и деагрегирование, тогда как классическая парадигма пересылки на базе IP-адреса получателя разрешает только агрегирование, (7) MPLS сравнительно легко интегрируется в модель маршрутизации на базе ограничений, (8) хорошая реализация MPLS может существенно снизить издержки, вносимые конкурирующими решениями для TE.

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

3.1 Индуцированный граф MPLS

В этом параграфе вводится концепция индуцированного графа MPLS⁹, который является важным элементом TE в домене MPLS. Индуцированный граф MPLS является аналогом виртуальной топологии в моделях с перекрытием. Он логически отображается на физическую сеть путем выбора LSP для транков трафика.

Индуцированный граф MPLS состоит из набора LSR, которые образуют узлы графа, и набора LSP, обеспечивающих соединения «точка-точка» между LSR и, следовательно, служащих ребрами индуцированного графа. Можно создать иерархию индуцированных графов MPLS на основе концепции стека меток, описанной в [1].

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

Пусть G = (V, E, c) — взвешенный граф, отражающий физическую топологию сети. Здесь V указывает множество узлов сети, а E — набор каналов (т. е., для узлов v и w из множества V объект (v,w) относится к множеству E, если узлы v и w напрямую соединены в рамках G). Параметр c содержит набор значений «емкости» и других ограничительных параметров, связанных с E и V. Будем называть граф G «базовой» топологией сети.

Пусть H = (U, F, d) — индуцированный граф MPLS. Здесь U — подмножество V, представляющее набор LSR в сети (или, более точно, набор LSR, являющихся конечными точками по крайней мере одного LSP). F — множество LSP, в котором для x и y из множества U объект (x, y) относится к множеству F, если существует LSP с конечными точками x и y. Параметр d задает набор потребностей и ограничений, связанных с F. Очевидно, что H является направленным графом. Можно видеть, что H зависит от параметров транзитивности графа G.

3.2 Фундаментальные проблемы организации трафика в MPLS

Существует три фундаментальных проблемы, связанных с TE в MPLS:

• как отображать пакеты в классы эквивалентной пересылки;
• как отображать классы эквивалентной пересылки в транки трафика;
• как отображать транки трафика на физическую топологию сети через пути с коммутацией по меткам.

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

4.0 Дополнительные возможности построения трафика в MPLS

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

Предлагаемая функциональность включает:

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

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

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

5.0 Атрибуты и характеристики транков

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

Сначала перечислим базовые свойства транков, используемые в этом документе:

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

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

Двумя наиболее значимыми вопросами являются (1) параметризация транков и (2) организация и обслуживание путей для транков.

5.1 Двухсторонние транки

Хотя транки трафика по своей природе являются односторонними, на практике зачастую полезно создавать одновременно два встречных транка между парой конечных точек. Два таких транка объединяются логически. Один транк, называемый прямым (forward), передает трафик от отправителя к получателю. Другой транк, называемый обратным (backward), служит для передачи трафика от получателя к отправителю. Будем называть объединение двух таких транков «двухсторонним транком» (BTT¹⁰) при выполнении двух условий:

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

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

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

5.2 Базовые операции в транках

Ниже перечислены базовые операции на транках трафика, значимые для целей TE.

• Establish (организация) — создание экземпляра транка трафика.
• Activate (активация) — активизация транка для начала передачи трафика. Организация и активация транка логически разделены, но могут быть реализованы или выполнены за одну операцию.
• Deactivate (деактивация) — действие по прекращению передачи через транк.
• Modify Attributes (изменение атрибутов) — действие по изменению атрибутов транка.
• Reroute (перемаршрутизация) — действие по изменению маршрута для транка. Это может быть административная операция или автоматически выполняемое действие протоколов нижележащего уровня.
• Destroy (разрушение) — действие по удалению экземпляра транка из сети и освобождению всех выделенных для него ресурсов (пространство меток и, возможно, полоса каналов).

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

5.3 Учет и мониторинг производительности

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

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

5.4 Базовые TE-атрибуты транков

Атрибутами транков трафика являются параметры, присвоенные транкам и влияющие на их поведение.

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

Наиболее значимые для TE базовые атрибуты транков перечислены ниже:

• атрибут параметров трафика;
• атрибут выбора пути и управления им;
• атрибут приоритета;
• атрибут очередности;
• атрибут гибкости;
• атрибут политики.

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

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

5.5 Атрибуты параметров трафика

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

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

5.6 Атрибуты выбора и поддержки пути

Атрибуты выбора и поддержки пути определяют правила выбора маршрута для транка и поддержки организованных путей.

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

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

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

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

5.6.1 Административно задаваемые явные пути

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

С явно заданными административными средствами путями следует связывать атрибут path preference rule¹¹. Этот атрибут представляет собой двоичную переменную, которая показывает, относится административно заданный путь к обязательным (mandatory) или необязательным (non-mandatory).

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

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

5.6.2 Иерархия правил предпочтения при множестве путей

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

5.6.3 Атрибуты приемлемости класса ресурсов

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

<resource-class, affinity>; <resource-class, affinity>; ..

Параметр resource-class задает класс ресурсов, для которого определяются отношения приемлемости (т. е., указывает, какие члены класса ресурсов будут включены в путь для транка или исключены из этого пути). Параметр affinity может быть двоичной переменной, принимающей значение для (1) явного включения или (2) явного исключения ресурса.

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

Если атрибуты приемлемости не заданы, используется отношение «не имеет значения» между транком и любыми ресурсами. В этом случае не предъявляется требований по явному включению или явному исключению тех или иных ресурсов для пути транка. На практике по умолчанию следует использовать этот вариант.

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

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

1. для явного включения отвергаются все ресурсы, не относящиеся к заданным классам, до начала расчета пути;
2. для явного исключения отвергаются все ресурсы, относящиеся к заданным классам, до начала расчета пути.

5.6.4 Атрибут адаптивности

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

Атрибут Adaptivity относится к параметрам поддержки пути, связанным с транком трафика. Связанный с транком атрибут адаптивности определяет возможность реоптимизации для транка. Этот атрибут представляет собой двоичную переменную, которая (1) разрешает или (2) запрещает реоптимизацию.

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

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

Реоптимизация отличается от отказоустойчивости. Для задания параметров устойчивости транка трафика к отказам используется другой набор атрибутов (см. параграф 5.9). На практике представляется разумным ждать от транков с реоптимизацией большей устойчивости к отказам в пути. Однако для транков без реоптимизации, чей путь административно задан, как обязательный (mandatory), также может требоваться устойчивость к отказам каналов и узлов пути.

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

5.6.5 Распределение нагрузки между параллельными транками

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

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

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

5.7 Атрибут приоритета

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

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

5.8 Атрибут вытеснения

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

Вытеснение может также использоваться для реализации политики приоритетного восстановления при отказах.

С помощью атрибута вытеснения можно установить четыре режима для транков трафика: (1) preemptor enabled, (2) non-preemptor, (3) preemptable и (4) non-preemptable. Транк в режиме preemptor enabled может вытеснять трафик транков с низким приоритетом, помеченных, как preemptable (вытесняемый). Трафик с атрибутом non-preemptable не может быть вытеснен другими транками, независимо от уровней приоритета для этих транков. Транк с атрибутом preemptable может быть вытеснен высокоприоритетными транками с атрибутом preemptor enabled.

Легко видеть, что некоторые из режимов вытеснения являются взаимоисключающими. С учетом приведенной выше нумерации режимов для транков допустимы комбинации атрибутов (1, 3), (1, 4), (2, 3) и (2, 4). По умолчанию следует использовать вариант (2, 4).

Транк A может вытеснить транк B только при выполнении всех 5 приведенных условий: (i) A имеет более высокий приоритет, (ii) A претендует на ресурсы, используемые B, (iii) имеющихся ресурсов недостаточно для одновременного использования транками A и B на основе того или иного деления, (iv) A имеет аттрибут preemptor enabled, (v) B имеет атрибут preemptable.

Атрибут вытеснения Preemption не рассматривается в качестве обязательного для принятой в современной сети Internet модели сервиса best effort, хотя он достаточно полезен. Однако в сценарии с дифференцированием услуг вытеснение становится более востребованным. Кроме того, в некоторых архитектурах межсетевого взаимодействия по оптическим каналам, когда часть функций защиты и восстановления переносится с уровня оптики на уровень сетевого оборудования (гигабитные и терабитные маршрутизаторы с коммутацией по меткам) для снижения расходов, стратегии вытеснения могут служить для снижения времени восстановления высокоприоритетных транков при отказах.

5.9 Атрибут отказоустойчивости

Атрибут отказоустойчивости определяет поведение транка при возникновении отказов на пути транка. В таких обстоятельствах требуется решать три основных задачи: (1) обнаружение отказа, (2) уведомление об отказе, (3) восстановление. Обычно реализации MPLS включают механизмы для решения всех этих задач.

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

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

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

Атрибуты отказоустойчивости предполагают тесное взаимодействие между MPLS и маршрутизацией.

5.10 Атрибут политики

Атрибут политики определяет действия, которые следует выполнять протоколам нижележащих уровней в тех случаях, когда транк трафика перестает соответствовать заданной политике (заданным в контракте параметрам трафика). В общем случае атрибуты политики могут определять для несоответствующего политике трафика ограничение скорости, маркировку или пересылку без выполнения каких-либо действий. При использовании политики для трафика выполнение соответствующих функций может осуществляться за счет адаптации используемых алгоритмов типа ATM Forum GCRA [11].

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

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

6.0 Атрибуты ресурсов

Атрибуты ресурсов относятся в параметрам состояния топологии и служат для ограничения маршрутизации трафика через заданные ресурсы.

6.1 Коэффициент выделения

Атрибут транка MAM¹² для ресурса представляет собой задаваемый административно параметр, который определяет часть ресурса, доступную для выделения этому транку. Этот атрибут применим, прежде всего, в пропускной способности. Однако его можно использовать и для буферных ресурсов LSR. Концепция MAM аналогична концепции подписки и бронирования в сетях Frame Relay и ATM.

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

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

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

6.2 Атрибут класса ресурсов

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

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

1. применения одинаковых правил к набору ресурсов, которые могут быть топологически разделены;
2. задания относительных предпочтений наборов ресурсов при организации пути транка;
3. явного ограничения размещение транков на указанных подмножествах ресурсов;
4. реализации обобщенных правил включения/исключения ресурсов;
5. реализации политики удержания локального трафика (правил, привязывающих локальный трафик к заданной топологической области сети).

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

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

7.0 Маршрутизация на базе ограничений

В этом разделе рассматриваются вопросы, связанные с маршрутизацией на базе ограничений в доменах MPLS. В современной терминологии маршрутизацию на базе ограничений часто называют QoS Routing¹³ [5,6,7,10].

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

Маршрутизация на базе ограничений обеспечивает сосуществование парадигмы маршрутизации с учетом потребностей и ограниченности ресурсов с протоколами поэтапной внутренней маршрутизации Internet.

При маршрутизации на базе ограничений входными данными для выбора маршрута являются:

• атрибуты, связанные с транками трафика;
• атрибуты, связанные с ресурсами;
• топологическая информация о состоянии сети.

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

Маршрутизация на базе ограничений позволяет существенно снизить объем ручной настройки конфигурации и участие операторов в реализации правил TE.

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

7.1 Базовые функции маршрутизации на основе ограничений

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

В общем виде задачи маршрутизации на базе ограничений не разрешимы для большинства реальных ситуаций. Однако на практике применимо очень простое эвристическое решение для поиска подходящего пути (см., например, [9]), если он существует:

• сначала отсечь ресурсы, которые не соответствуют требованиям в атрибутах транка;

• использовать алгоритм поиска кратчайшего пути в оставшейся части графа.

    ------------------------------------------
   |           Интерфейс управления           |
    ------------------------------------------
       |                |                  |
 ----------     -----------------    -------------
|    MPLS  |<->|     Процесс     |  |   Обычный   |
|          |   |  маршрутизации  |  | процесс IGP |
 ----------     -----------------    -------------
                    |                     |
      -----------------------    ------------------
     |    База данных о      |  | База данных о    |
     | доступности ресурсов  |  | состоянии каналов|
      -----------------------    ------------------

Рисунок 1. Процесс Constraint-Based Routing в Layer 3 LSR

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

7.2 Вопросы реализации

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

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

1. расширить протоколы IGP (типа OSPF и IS-IS) для поддержки маршрутизации на базе ограничений (такие усилия для протокола OSPF уже предпринимаются [5,7]);
2. добавить процесс маршрутизации на базе ограничений в маршрутизаторы IGP (см . Рисунок 1).

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

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

• механизмы поддержки топологической информации;

• взаимодействие процессов маршрутизации на базе ограничений и IGP;
• механизмы адаптации требований адаптивности транков;
• механизмы адаптации требований отказоустойчивости и жизнестойкости транков.

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

8.0 Заключение

В этом документе представлен набор требований для TE в MPLS. Описано множество возможностей повышения уровня применимости MPLS к построению трафика в Internet.

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

9.0 Вопросы безопасности

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

10.0 Литература

[1] Rosen, E., Viswanathan, A. and R. Callon, «A Proposed Architecture for MPLS», Work in Progress¹⁴.

[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G. and A. Viswanathan, «A Framework for Multiprotocol Label Switching», Work in Progress¹⁵.

[3] Li, T. and Y. Rekhter, «Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)», RFC 2430, October 1998.

[4] Rekhter, Y., Davie, B., Katz, D., Rosen, E. and G. Swallow, «Cisco Systems’ Tag Switching Architecture — Overview», RFC 2105, February 1997.

[5] Zhang, Z., Sanchez, C., Salkewicz, B. and E. Crawley «Quality of Service Extensions to OSPF», Work in Progress¹⁶.

[6] Crawley, E., Nair, F., Rajagopalan, B. and H. Sandick, «A Framework for QoS Based Routing in the Internet», RFC 2386, August 1998.

[7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. and D. Williams, «QoS Routing Mechanisms and OSPF Extensions», RFC 2676, August 1999.

[8] C. Yang and A. Reddy, «A Taxonomy for Congestion Control Algorithms in Packet Switching Networks,» IEEE Network Magazine, Volume 9, Number 5, July/August 1995.

[9] W. Lee, M. Hluchyi, and P. Humblet, «Routing Subject to Quality of Service Constraints in Integrated Communication Networks,» IEEE Network, July 1995, pp 46-55.

[10] ATM Forum, «Traffic Management Specification: Version 4.0» April 1996.

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

Авторы благодарят Yakov Rekhter за просмотр черновых вариантов документа. Авторы также выражают свою благодарность Louis Mamakos и Bill Barns за внесенные предложения и Curtis Villamizar за полезные отклики.

12.0 Адреса авторов

Daniel O. Awduche

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-208-5277

EMail: awduche@uu.net

Joe Malcolm

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-206-5895

EMail: jmalcolm@uu.net

 

Johnson Agogbua

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-206-5794

EMail: ja@uu.net

 

Mike O’Dell

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-206-5890

EMail: mo@uu.net

 

Jim McManus

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-206-5607

EMail: jmcmanus@uu.net

---

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

13.0 Полное заявление авторских прав

Copyright (C) The Internet Society (1999). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

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

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

Network Working Group                                         B. Fox
Request for Comments: 2685                       Lucent Technologies
Category: Standards Track                                 B. Gleeson
                                                     Nortel Networks
                                                      September 1999

Идентификатор виртуальной частной сети (VPN)

Virtual Private Networks Identifier

PDF

Статус документа

Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

Аннотация

Виртуальные частные сети IP могут покрывать множество автономных систем (AS) или сетей сервис-провайдеров (SP). Это порождает требование использования уникальных в глобальном масштабе идентификаторов VPN, которые позволят определить конкретные VPN (см. параграф 6.1.1 в документе [1]). В данном документе предложен формат уникального в глобальном масштабе идентификатора VPN.

1. Введение

По мере расширения публичной сети Internet и глобального расширения сетевой инфраструктуры существенно возрос интерес в виртуальным частным сетям (VPN¹) на основе IP. VPN эмулирует частную сеть IP через публичные или разделяемые инфраструктуры. Сети VPN обеспечивают ряд преимуществ как для сервис-провайдеров, так и для их заказчиков. Для заказчиков VPN позволяет включить в единую сеть IP удаленные офисы и отдельных пользователей подключаемых к сети разными способами. Подключение к сети в каждом случае может осуществляться наиболее экономичным способом и это позволяет снизить расходы заказчика на оборудование, услуги и поддержку. Сервис-провайдеры могут повысить эффективность использования своей инфраструктуры, предлагая своим заказчикам подключение и/или услуги IP VPN.

Существует множество способов реализации услуг IP VPN. В базовом документе по таким сетям [1] выделены четыре типа поддерживаемых VPN: виртуальные выделенные линии (VLL²), виртуальные частные маршрутизируемые сети (VPRN³), виртуальные частные сети с коммутируемым доступом (VPDN⁴) и сегменты виртуальных частных ЛВС (VPLS⁵). В дополнение к упомянутому документу во множестве проектов спецификация описаны методы, которые могут использоваться сервис-провайдерами и/или их заказчиками для организации сервиса VPN. Решения могут выбираться для отдельных заказчиков или сети в целом. Сетевые решения могут обеспечивать подключение и услуги уровня 2 и/или 3. Устройствами, вовлеченными в реализацию решения могут быть оборудование заказчика (CPE⁶), оконечное оборудование сервис-провайдера (SPE⁷), и оборудование ядра сети сервис-провайдера, а также комбинации этих устройств.

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

поскольку VPN является частной сетью, в ней могут использоваться блоки адресов, которые могут перекрываться с блоками других VPN или публичной сети Internet;

VPN может простираться через множество автономных систем (AS) IP или сервис-провайдеров.

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

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

2. Глобальный идентификатор VPN

Задачей VPN-ID является идентификация VPN. Этот идентификатор может использоваться разными способами в зависимости от метода реализации сервиса VPN. Например, VPN-ID может быть включен:

• в базу MIB для конфигурирования атрибутов VPN или выделения физического или логического интерфейса доступа для конкретной VPN;

• в пакет данных управления для идентификации «зоны действия» приватного адреса IP и VPN, к которой относятся данные.

Необходимо обеспечить возможность идентификации VPN, с которой связан пакет данных. Идентификатор VPN-ID может использоваться для решения этой задачи явно (например, путем включения VPN-ID в заголовок инкапсуляции [2]) или неявно (например, путем включения VPN-ID в сигнальный обмен ATM [3]). Приемлемость использования VPN-ID в других вариантах контекста требует внимательного изучения.

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

Эти функции требуют глобальной зоны действия идентификатора VPN и возможности его использования в разных решениях. Для того, чтобы идентификатор VPN был уникальным в глобальном масштабе, формат идентификатора не должен основываться на каких-либо допущениях о разделяемой сети (сетях). И наоборот, формат не следует определять таким образом, чтобы возникали ограничения на использование возможностей разделяемой сети (сетей). Необходимо отметить, что одна и та же VPN может идентифицироваться на разных уровнях одной разделяемой сети (например, на уровнях ATM и IP). Для обоих уровнях следует в таких случаях использовать общее значение и формат VPN-ID.

Методы использования VPN-ID выходят за пределы данного документа.

3. Требования к формату глобального идентификатора VPN

К формату идентификатора VPN следует предъявлять перечисленные здесь требования:

• значение идентификатора VPN должно быть уникальным и используемым в сетях разных сервис-провайдеров;
• должны поддерживаться не связанные с IP идентификаторы VPN-ID для использования в VPN канального уровня.

• VPN-ID должен идентифицировать VPN Authority.

4. Формат глобального идентификатора VPN

Глобальный идентификатор VPN включает

3-октетный идентификатор агентства VPN (VPN OUI⁸) [4]

за которым следует

4-октетный индекс VPN (VPN Index), идентифицирующий VPN в рамках OUI

   0 1 2 3 4 5 6 7 8
   +-+-+-+-+-+-+-+-+
   | VPN OUI (MSB) |
   +-+-+-+-+-+-+-+-+
   |   VPN OUI     |
   +-+-+-+-+-+-+-+-+
   | VPN OUI (LSB) |
   +-+-+-+-+-+-+-+-+
   |VPN Index (MSB)|
   +-+-+-+-+-+-+-+-+
   |  VPN Index    |
   +-+-+-+-+-+-+-+-+
   |  VPN Index    |
   +-+-+-+-+-+-+-+-+
   |VPN Index (LSB)|
   +-+-+-+-+-+-+-+-+

VPN OUI (IEEE 802-1990 Organizationally Unique Identifier) [4] идентифицирует Агентство VPN. Этот орган будет являться основным администратором VPN. Агентством может быть компания/организация, к которой относится VPN, или сервис-провайдер, обеспечивающий инфраструктуру VPN с использованием своей (или других сервис-провайдеров) разделяемой сети. 4-октетный индекс VPN идентифицирует отдельную VPN, обслуживаемую агентством VPN.

5. Вопросы безопасности

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

6. Литература

[1] Gleeson, Heinanen, Lin, Armitage, Malis, «A Framework for IP Based Virtual Private Networks», Work in Progress⁹.

[2] Grossman, D. and J. Heinanen, «Multiprotocol Encapsulation over ATM Adaptation Layer 5», RFC 2684, September 1999.

[3] «MPOA v1.1 Addendum on VPN Support», ATM Forum, af-mpoa-0129.000, August, 1999, Bernhard Petri, editor, final ballot document.

[4] http://standards.ieee.org/regauth/oui/index.html

7. Адреса авторов

Barbara A. Fox

Lucent Technologies

300 Baker Ave, Suite 100

Concord, MA 01742-2168

Phone: +1-978-287-2843

EMail: barbarafox@lucent.com

 

Bryan Gleeson

Nortel Networks

4500 Great America Parkway,

Santa Clara, CA 95054

Phone: +1-408-855-3711

EMail: bgleeson@shastanets.com

---

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

8. Полное заявление авторских прав

Copyright (C) The Internet Society (1999). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

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

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

Network Working Group                                    D. Grossman
Request for Comments: 2684                            Motorola, Inc.
Obsoletes: 1483                                          J. Heinanen
Category: Standards Track                                      Telia
                                                      September 1999

 

Многопротокольная инкапсуляция с использованием AAL.5

Multiprotocol Encapsulation over ATM Adaptation Layer 5

PDF

Статус документа

Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (1999). Все права защищены.

Аннотация

Этот документ заменяет RFC 1483. Документ описывает два метода инкапсуляции при передаче межсетевого трафика с использованием AAL типа 5 по сети ATM. Первый метод позволяет мультиплексировать множество протоколов через одно виртуальное соединение ATM, а во втором методе предполагается наличие отдельного виртуального соединения ATM для каждого из протоколов.

Применимость

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

1. Введение

Глобальные, кампусные и локальные сети ATM используются для доставки дейтаграмм IP и другого трафика, не требующего организации соединений, между хостами, маршрутизаторами, мостами и другими сетевыми устройствами. В данном документе описываются два метода транспортировки протокольных модулей данных PDU, не требующих организации соединений и использующих маршрутизацию или мосты, через сети ATM. Метод инкапсуляции LLC (LLC Encapsulation) позволяет мультиплексировать множество протоколов через одно виртуальное соединение ATM (VC). Тип протокола для каждого PDU идентифицируется заголовком уровня управления логическим каналом — IEEE 802.2 LLC. При использовании метода мультиплексирования виртуальных соединений (VC Multiplexing) каждое из виртуальных соединений ATM VC служит для передачи PDU только одного протокола. При необходимости транспортировки множества протоколов для каждого из них организуется отдельное виртуальное соединение.

В сетях ATM для передачи данных используются блоки размером 53 октета, которые называют ячейками. Каждая ячейка содержит заголовок размером 5 октетов и 48 октетов информации (payload). PDU переменной длины (включая и описываемые в настоящем документе) должны быть сегментированы для размещения в 48-байтовых информационных полях ячеек ATM. На приемной стороне должна обеспечиваться обратная операция по сборке сегментированных пакетов. В данном документе описывается использование для решения этой задачи уровня адаптации AAL5 (ATM Adaptation Layer type 5) в соответствии с рекомендациями ITU-T (I.363.5 [2]). PDU переменной длины передаются в полях Payload ячеек подуровня AAL5 Common Part Convergence (CPCS).

Данный документ описывает только передачу PDU, требующих маршрутизации или организации мостов, непосредственно через AAL5 CPCS (т. е., подуровень SSCS¹ AAL5 отсутствует). Если поверх CPCS используется подуровень FR-SSCS (Frame Relay Service Specific Convergence Sublayer), описанный в рекомендациях ITU-T (I.365.1 [3]), PDU, требующие маршрутизации или организации мостов, передаются с использованием мультиплексирования NLPID, описанного в RFC 2427 [4]. Инкапсуляция RFC 2427 должна использоваться в тех случаях, когда применяется Frame Relay Network Interworking или Service Interworking в прозрачном режиме [9]; не рекомендуется использовать такую инкапсуляцию для других приложений. В Приложении A (исключительно с информационной целью) описан формат FR-SSCS-PDU для случаев инкапсуляции пакетов IP и CLNP в FR-SSCS в соответствии с RFC 2427.

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

Если вы хотите использовать возможности протокола PPP и существуют прямые (точка-точка) связи между системами одного уровня (peer systems), обратитесь к RFC 2364, где содержится информация, применимая к таким задачам.

2. Соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [10].

3. Выбор метода мультиплексирования

Выбор метода инкапсуляции (LLC или мультиплексирование VC) зависит от реализации и системных требований. В общем случае инкапсуляция LLC применяется для снижения числа используемых VC. Мультиплексирование VC позволяет снизить объем передаваемых в результате фрагментации заголовков (например, при передаче дейтаграмм IPv4, содержащих пакеты управления TCP, заголовки IP и TCP не вписываются в одну ячейку).

Когда оконечные системы ATM хотят обмениваться PDU без организации соединений через ATM PVC², выбор метода мультиплексирования задается конфигурацией. При использовании коммутируемых виртуальных соединений ATM (SVC) для согласования метода инкапсуляции служат сигнальные процедуры управления соединениями ATM. Процедуры согласования описаны в документах [5] и [8].

4. Формат AAL5 PDU

Для обоих вариантов мультиплексирования PDU, требующие маршрутизации или организации мостов, должны инкапсулироваться в поля Payload пакетов AAL5 CPCS-PDU.

Рекомендации ITU-T I.363.5 [2] содержат полное определение формата AAL5 PDU и описание процедур приема и передачи. Должен использоваться сервис режима сообщений AAL5 (message mode service) без обеспечения гарантий (non-assured). Использование опции corrupted delivery (доставка при повреждении) является недопустимым. Может использоваться таймер сборки ячеек (reassembly timer). Ниже приведено описание формата AAL5 CPCS-PDU.

. . CPCS-PDU Payload до 216 — 1 октетов (65535) . .
PAD (заполнение) — 0 — 47 октетов
CPCS-UU — 1 октет	Трейлер CPCS-PDU
CPI — 1 октет
Длина — 2 октета
CRC — 4 октета

Поле Payload содержит пользовательскую информацию и может иметь размер до 2¹⁶ — 1 октетов.

Поле PAD (заполнение) служит для выравнивания CPCS-PDU по границе ячеек ATM так, чтобы последнее 48-октетное поле, создаваемое подуровнем SAR (фрагментация и сборка пакетов) совпадало с границей трейлера CPCS-PDU.

Поле CPCS-UU (индикация пользователь-пользователь) служит для прозрачной передачи информации CPCS между пользователями. Это поле не используется при мультипротокольной инкапсуляции ATM, описываемой в данном документе, и может иметь любое значение.

Поле CPI (Common Part Indicator — индикатор общей части) выравнивает трейлер CPCS-PDU по 64-битовой границе. Поле должно иметь значение 0x00.

Поле Length (длина) указывает размер поля Payload в октетах. Максимальное значение этого поля составляет 65535. Значение Length = 0x00 используется в качестве функции прерывания.

Поле CRC (контрольная сумма) служит для обнаружения ошибок в CPCS-PDU с помощью алгоритма CRC-32.

5. Инкапсуляция LLC

Инкапсуляция LLC нужна в тех случаях, когда требуется передача множества протоколов с использованием одного виртуального соединения (VC). Для того, чтобы на приемной стороне была возможность корректной обработки входящих AAL5 CPCS-PDU, поле Payload содержит информацию, обеспечивающую идентификацию протокола PDU, для которого нужна маршрутизация или организация моста. При инкапсуляции LLC эта информация должна содержаться в заголовке LLC, размещаемом в начале передаваемого пакета PDU.

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

5.1. LLC-инкапсуляция для маршрутизируемых протоколов

При использовании инкапсуляции LLC тип протоколов PDU, для которых нужна маршрутизация или организация мостов, должен указываться с помощью префиксов заголовка IEEE 802.2 LLC для каждого PDU. В некоторых случаях вслед за заголовком LLC должен размещаться заголовок IEEE 802.1a SNAP (SubNetwork Attachment Point). При работе с LLC типа 1 заголовок LLC должен содержать три 1-октетных поля:

DSAP

SSAP

Control

При инкапсуляции LLC для маршрутизируемых протоколов поле Control должно иметь значение 0x03, указывающее на UI (Unnumbered Information) Command PDU.

Значение заголовка LLC 0xFE-FE-03 должно использоваться для идентификации маршрутизируемых PDU в формате ISO NLPID (см. [6] и Приложение B). Для NLPID-форматируемых и маршрутизируемых PDU поле Payload в AAL5 CPCS-PDU должно иметь следующий формат:

LLC 0xFE-FE-03

NLPID (1 октет)

. PDU (до 216 — 4 октетов) .

Маршрутизируемые протоколы должны идентифицироваться 1-октетным полем NLPID, которое является частью протокольных данных (Protocol Data). Значения NLPID выделяются ISO и ITU-T. Текущие значения идентификаторов определены в документе ISO/IEC TR 9577 [6], некоторые из этих значений приведены в Приложении C.

Значение NLPID = 0x00 определено в ISO/IEC TR 9577 как Null Network Layer или Inactive Set. Поскольку это значение не имеет смысла в контексте данной схемы инкапсуляции, использование NLPID = 0x00 недопустимо.

Хотя существует значение NLPID (0xCC) для индикации протокола IP, формат NLPID недопустимо использовать для IP. Вместо этого дейтаграммы IP должны указываться заголовком SNAP, описанным ниже.

Присутствие заголовка IEEE 802.1a SNAP обозначается заголовком LLC = 0xAA-AA-03. Заголовок SNAP имеет форму:

OUI

PID

Заголовок SNAP содержит 3-октетный идентификатор организации OUI (Organizationally Unique Identifier) и 2-октетный идентификатор протокола PID. Значения OUI выдаются IEEE и идентифицируют организацию, которая администрирует значения PID. Таким образом, заголовок SNAP обеспечивает уникальную идентификацию для протоколов маршрутизации и мостов. Значение OUI = 0x00-00-00 показывает, что поле PID содержит значение EtherType.

Формат поля Payload для AAL5 CPCS-PDU маршрутизируемых протоколов, не относящихся к NLPID, показан ниже.

LLC 0xAA-AA-03

OUI 0x00-00-00

EtherType (2 октета)

. PDU с отличным от NLPID форматом (до 216 — 9 октетов) .

Для частного случая IPv4 PDU значение Ethertype = 0x08-00 и поле Payload должно использовать формат:

LLC 0xAA-AA-03

OUI 0x00-00-00

EtherType 0x08-00

. IPv4 PDU (до 216 — 9 октетов) .

Этот формат согласуется с определением RFC 1042 [7].

5.2. Инкапсуляция LLC для Bridged-протоколов

При использовании инкапсуляции LLC PDU, требующие организации мостов, инкапсулируются путем идентификации bridged-среды в заголовке SNAP. Присутствие заголовка SNAP должно указываться с помощью заголовка LLC = 0xAA-AA-03. Значение OUI в заголовке SNAP должно быть кодом организации для 802.1 (0x00-80-C2). Тип bridged-среды должен задаваться 2-октетным значением PID. Поле PID должно также говорить о реальном присутствии контрольной суммы FCS (Frame Check Sequence) в передаваемом через мосты PDU. В Приложении B приведен список типов сред (значений PID), которые могут использоваться при ATM-инкапсуляции.

Поле Payload в AAL5 CPCS-PDU, служащее для переноса PDU, требующих организации мостов, должно использовать один из рассмотренных ниже форматов. После поля PID должны быть добавлены октеты заполнения для выравнивания полей Ethernet/802.3 LLC Data, 802.4 Data Unit, 802.5 Info, FDDI Info или 802.6 Info передаваемого через мосты PDU по 4-октетной границе. Порядок битов MAC-адреса должен быть такой же, какой используется в ЛВС или MAN (например, канонический для Ethernet/IEEE 802.3 PDU или 802.5/FDDI для 802.5 PDU).

Формат для пакетов Bridged Ethernet/802.3 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-01 или 0x00-07

PAD 0x00-00

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-01)

Физический уровень Ethernet/802.3 требует заполнения кадров до минимального размера. Мост, который использует формат инкапсуляции Bridged Ethernet/802.3 с сохраненным полем LAN FCS, должен включать заполнение. Мост, который использует формат инкапсуляции Bridged Ethernet/802.3 без сохранения контрольной суммы LAN FCS может не включать битов заполнения. Когда мост принимает кадр в таком формате без контрольной суммы LAN FCS, он должен вставить требуемые биты заполнения (если их нет) до передачи кадра в подсеть Ethernet/802.3 .

Формат Payload для пакетов Bridged 802.4 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-02 или 0x00-08

PAD 0x00-00-00

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-02)

Формат поля Payload для пакетов Bridged 802.5 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-03 или 0x00-09

PAD 0x00-00-XX

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-03)

Поскольку поле управления доступом 802.5 AC не имеет значения за пределами локальной подсети 802.5, это поле трактуется при данном способе инкапсуляции как последний октет 3-октетного поля заполнения PAD. Это поле может иметь любое значение (устанавливает передающий мост), а принимающий мост должен просто игнорировать значение данного поля.

Формат поля Payload для пакетов Bridged FDDI PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-04 или 0x00-0A

PAD 0x00-00-00

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-04)

Формат поля Payload для пакетов Bridged 802.6 PDU

LLC 0xAA-AA-03
OUI 0x00-80-C2
PID 0x00-0B
Резервное поле	BEtag	Общий заголовок PDU
BAsize
MAC-адрес получателя
(остальная часть кадра MAC)
Общий трейлер PDU

В передаваемых с использованием мостов пакетов 802.6 PDU присутствие поля CRC-32 указывается битом CIB в заголовке кадра MAC. Следовательно, во всех случаях используется одно значение PID (независимо от присутствия контрольной суммы CRC-32 в PDU).

Заголовок и трейлер Common PDU передаются для того, чтобы обеспечить возможность организации конвейерной обработки (pipelining) на мосту, являющемся выходом в подсеть 802.6. В частности, заголовок Common PDU содержит поле BAsize, в котором указан размер PDU. Если это поле недоступно выходному мосту 802.6, этот мост не сможет начать передачу сегментированного PDU до тех пор, пока PDU не будет принят полностью, рассчитан его размер и значение размера не будет помещено в поле BAsize. Если данное поле доступно, выходной мост 802.6 может определить размер пакета из поля BAsize в заголовке Common PDU, вставить это значение в соответствующее поле первого сегмента и незамедлительно начать передачу сегмента в подсеть 802.6. Таким образом, мост может начать передачу пакета 802.6 PDU до того, как будет завершен прием всего PDU.

Отметим, что заголовок и трейлер Common PDU Header инкапсулируемого кадра не должны просто копироваться в выходную (outgoing) подсеть 802.6, поскольку инкапсулированное значение BEtag может конфликтовать с предыдущим значением Betag, переданным этим мостом.

Входной мост 802.6 может прервать пакет AAL5 CPCS-PDU, установив Length=0. Если выходной мост уже начал передачу сегментов этого PDU в подсеть 802.6, этому мосту передается уведомление о том, что передача AAL5 CPCS-PDU прервана — в результате может быть незамедлительно сгенерирована ячейка EOM, приводящая к отказу от 802.6 PDU на принимающем мосту. Такая ячейка EOM может, к примеру, содержать некорректное значение поля Length в трейлере Common PDU .

Формат поля Payload для пакетов BPDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-0E

6. Мультиплексирование VC

При мультиплексировании виртуальных соединений VC организуются ассоциации между ATM VC и типом сетевого протокола, передаваемого с помощью этого VC. Таким образом, в данной ситуации не нужно передавать информацию для идентификации протокола в информационном поле каждого AAL5 CPCS-PDU. Это снижает объем служебной информации (overhead) и упрощает обработку пакетов. Мультиплексирование VC может повысить эффективность передачи пакетов за счет снижения числа ячеек, требуемых для передачи PDU определенной длины.

Для ATM PVC тип протокола, передаваемого через каждое постоянное соединение (PVC), должен задаваться конфигурацией. Для коммутируемых соединений ATM SVC должно использоваться согласование на основе RFC 1755 [5].

6.1. VC-мультиплексирование для маршрутизируемых протоколов

PDU маршрутизируемых протоколов должны передаваться только как содержимое информационных полей (Payload) пакетов AAL5 CPCS-PDU. Формат поля Payload пакетов AAL5 CPCS-PDU рассмотрен ниже.

Формат поля Payload для маршрутизируемых PDU

. Передаваемый пакет PDU (до 216 — 1 октетов) .

6.2. VC-мультиплексирование для Bridged-протоколов

PDU для протоколов, использующих мосты, должны передаваться в поле Payload пакетов AAL5 CPCS-PDU в точности так же, как было описано в параграфе 5.2. Единственным отличием является то, что после PID должно включаться только одно поле. Поля Payload для пакетов AAL5 CPCS-PDU при передаче трафика с использованием мостов должны, следовательно, использовать приведенные ниже форматы.

Формат поля Payload для пакетов Bridged Ethernet/802.3 PDU

PAD 0x00-00

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (зависит от VC)

Формат поля Payload для пакетов Bridged 802.4/802.5/FDDI PDU

PAD 0x00-00-00 или 0x00-00-XX

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (зависит от VC)

Отметим, что поле 802.5 AC (Access Control — управление доступом) не имеет смысла за пределами локальной подсети 802.5. Это касается последнего октета 3-байтового поля PAD, которое для кадров 802.5 может принимать любое значение (XX).

Формат поля Payload для пакетов Bridged 802.6 PDU

Резервное поле	BEtag	Общий заголовок PDU
BAsize
MAC-адрес получателя
(остальная часть кадра MAC)
Общий трейлер PDU

Формат поля Payload для пакетов BPDU

BPDU в соответствии с 802.1(d) или 802.1(g)

Для пакетов Ethernet, 802.3, 802.4, 802.5 и FDDI наличие или отсутствие завершающего поля LAN FCS должно явно указываться VC, поскольку поле PID не включается. Пакеты PDU с LAN FCS и PDU без LAN FCS рассматриваются как относящиеся к различным протоколам, даже если тип сред, для которых организуется мост, совпадает.

7. Организация мостов в сетях ATM

Мост с интерфейсом ATM, служащий в качестве канала связи с одним или несколькими мостами, должен быть способен фильтровать, пересылать и распространять всем (flood) пакеты PDU, пересылаемые через мост.

Лавинная маршрутизация (Flooding) выполняется путем передачи PDU по всем возможным и приемлемым адресам. В среде ATM это означает, что PDU будет передаваться через все, относящиеся к делу VC. Это может выполняться путем явного копирования пакета в каждое соединение VC или за счет организации виртуальных соединений “один со многими” (point-to-multipoint VC).

Для пересылки PDU мост должен быть способен связать MAC-адрес получателя с VC. Неразумно (а в некоторых случаях — невозможно) требовать статической настройки мостов для создания ассоциаций между всеми возможными MAC-адресами получателей и VC. Следовательно, мосты ATM должны предоставлять достаточную информацию для того, чтобы интерфейс ATM мог динамически определять такие ассоциации.

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

8. Идентификация VPN

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

Механизм глобальной идентификации многопротокольных VPN описан в документе [11]. Семиоктетное поле VPN-Id содержит 3-октетный идентификатор OUI (IEEE 802-1990 Organizationally Unique Identifier), связанный с VPN, за которым следует 4-октетный индекс VPN, связанный с владельцем VPN-related OUI. Обычно значения VPN-related OUI предоставляются поставщикам услуг VPN, которые выделяют индексы VPN своим заказчикам.

8.1 Заголовок инкапсуляции VPN

Форматы заголовков VPN-инкапсуляции рассмотрены ниже:

Заголовок инкапсуляции VPN

LLC 0xAA-AA-03

OUI 0x00-00-5E

PID 0x00-08

PAD 0x00

VPN related OUI (3 октета)

VPN Index (4 октета)

(остальная часть PDU)

При использовании заголовка инкапсуляции остальная часть PDU должна быть структурирована в соответствии с приемлемым форматом из числа описанных в параграфах 5 и 6 (т.е. заголовок инкапсуляции VPN предшествует PDU в пакете AAL5 CPCS SDU).

8.2 Маршрутизация и мосты для PDU с LLC-инкапсуляцией в VPN

Когда пакеты с LLC-инкапсуляцией передаются с использованием маршрутизации или мостов внутри VPN, использующей ATM поверх AAL5, заголовок инкапсуляции VPN должен предшествовать заголовку соответствующего формата PDU для маршрутизации или мостов (см. параграф 5.1 и 5.2).

8.3 Мультиплексирование VC для PDU внутри VPN

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

Если VPN указывается с использованием сигнализации управления соединениями ATM, все PDU, передаваемые с помощью ATM VC, связываются с одной VPN. В этом случае формат информационных полей для PDU с использованием маршрутизации или мостов должен определяться в соответствии с параграфами 6.1 и 6.2. Если PDU принимается с заголовком инкапсуляции VPN, при идентификации VPN с помощью сигнализации ATM приемник может отбрасывать такие пакеты и/или выполнять по отношению с ним иные действия (в зависимости от реализации). Описание использования механизмов сигнализации контроля соединений ATM для передачи идентификаторов VPN выходит за пределы данного документа.

Если идентификаторы VPN административно выделяются для интерфейса ATM, все PDU, передаваемые через любые ATM VC на одном интерфейсе, оказываются связанными с одной VPN. В этом случае формат информационных полей PDU с использованием маршрутизации или мостов должен соответствовать описаниям, приведенным в параграфах 6.1 и 6.2. Если принимаемый PDU содержит заголовок инкапсуляции VPN при административном распределении идентификаторов VPN, принимающая сторона может отбросить такие пакеты и/или выполнить по отношению к ним иные действия (в зависимости от реализации). Рассмотрение механизмов (таких как MIB) распределения идентификаторов VPN на интерфейсах ATM выходит за пределы настоящего документа.

Если идентификатор VPN указывается с использованием заголовка инкапсуляции, заголовок инкапсуляции VPN должен предшествовать PDU для маршрутизации или мостов с соответствующим форматом (см. параграфы 6.1 и 6.2).

9. Вопросы безопасности

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

На безопасность системы могут оказывать влияние и свойства нижележащих уровней ATM. ATM Forum публикует материалы по безопасности, в которых можно найти информацию, связанную с инкапсуляцией ([12], [13]).

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

Этот документ заменяет RFC 1483, разработанный группой IP over ATM и подготовленный Juha Heinanen (в то время Telecom Finland, сейчас — Telia). Данный документ был создан в рабочей группе IP-over-NBMA (ION) и Dan Grossman (Motorola) — один из авторов — принимал участие и в разработке RFC 1483.

В данном документе содержатся переработанные материалы из других RFC ([1] и [4]). Спасибо авторам этих документов — Terry Bradley, Caralyn Brown, Andy Malis, Dave Piscitello и C. Lawrence. Важный вклад в работу внесли Carpenter (CERN), Rao Cherukuri (IBM), Joel Halpern (в тот момент Network Systems), Bob Hinden (Sun Microsystems, сейчас — Nokia) и Gary Kessler (MAN Technology).

Материалы, связанные с VPN, подготовили Barbara Fox (Lucent) и Bernhard Petri (Siemens).

Литература

[1] Piscitello, D. и C. Lawrence, «The Transmission of IP Datagrams over the SMDS Service», RFC 1209, март 1991.

[2] ITU-T Recommendation I.363.5, «B-ISDN ATM Adaptation Layer (AAL) Type 5 Specification», август 1996.

[3] ITU-T Recommendation I.365.1, «Frame Relaying Service Specific Convergence Sublayer (SSCS), ноябрь 1993.

[4] Brown, C. и A. Malis, «Multiprotocol Interconnect over Frame Relay», RFC 2427, сентябрь 1998.

[5] Perez M., Liaw, F., Mankin, E., Grossman, D. и A. Malis, «ATM Signalling Support for IP over ATM», RFC 1755, февраль 1995.

[6] Information technology — Telecommunications and Information Exchange Between Systems, «Protocol Identification in the Network Layer». ISO/IEC TR 9577, октябрь 1990.

[7] Postel, J. и J. Reynolds, «A Standard for the Transmission of IP Datagrams over IEEE 802 Networks», STD 43, RFC 1042, февраль 1988.

[8] Maher, M., «IP over ATM Signalling — SIG 4.0 Update», RFC 2331, апрель 1998.

[9] ITU-T Recommendation I.555, «Frame Relay Bearer Service Interworking», сентябрь 1997.

[10] Bradner, S. «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, март 1997.

[11] Fox, B. and B. Gleeson, «Virtual Private Networks Identifier», RFC 2685, сентябрь 1999.

[12] The ATM Forum, «ATM Security Framework Version 1.0», af-sec-0096.000, февраль 1998.

[13] The ATM Forum, «ATM Security Specification v1.0», af-sec-0100.001, февраль 1999.

Приложение A. Многопротокольная инкапсуляция поверх FR-SSCS

Рекомендации ITU-T I.365.1 определяют связанный с коммутацией кадров подуровень конвергенции FR-SSCS (Frame Relaying Specific Convergence Sublayer) для использования поверх общей части подуровня конвергенции CPCS (Common Part Convergence Sublayer) AAL типа 5 для межсетевого взаимодействия Frame Relay/ATM. Сервис, предоставляемый FR-SSCS, соответствует Core-сервису для коммутации кадров (Frame Relaying), описанной в I.233.

Пакеты FR-SSCS-PDU содержат поле адреса Q.922, за которым следует информационное поде Q.922. Флаги Q.922 и FCS не используются, поскольку соответствующие функции обеспечиваются AAL. Ниже показан формат FR-SSCS-PDU, вложенных в поле Payload пакетов AAL5 CPCS-PDU.

             FR-SSCS-PDU в поле Payload пакетов AAL5 CPCS-PDU
            +-------------------------------+ -------
            |      Поле адреса Q.922        | Заголовок FR-SSCS-PDU 
            |         (2-4 octets)          |
            +-------------------------------+ -------
            |             .                 |
            |             .                 |
            |    Информационное поле Q.922  | Данные FR-SSCS-PDU 
            |             .                 |
            |             .                 |
            +-------------------------------+ -------
            |      Трейлер AAL5 CPCS-PDU    |
            +-------------------------------+

PDU, использующие маршрутизацию или мосты, инкапсулируются в FR-SSCS-PDU в соответствии с RFC 2427. Информационное поле Q.922 начинается с поля Q.922 Control, за которым следует необязательный октет заполнения, используемый для выравнивания остальной части кадра по приемлемой для отправителя границе. Протокол передаваемых PDU указывается с помощью предшествующих PDU идентификаторов протокола сетевого уровня ISO/IEC TR 9577 NLPID.

В частном случае IP PDU идентификатор NLPID = 0xCC и пакет FR-SSCS-PDU имеет следующий формат:

Формат FR-SSCS-PDU для маршрутизируемых IP PDU

Поле адреса Q.922 (2 или 4 октета)

0x03 (Q.922 Control)

NLPID 0xCC

. IP PD (до 216 — 5 октетов) .

Отметим, что согласно RFC 2427, адрес Q.922 должен содержать 2 или 4 октета, т.е. 3-октетные адреса использовать недопустимо.

Для частного случая CLNP PDU идентификатор NLPID = 0x81 и формат FR-SSCS-PDU приведен ниже:

Формат FR-SSCS-PDU для маршрутизируемых CLNP PDU

Поле адреса Q.922 (2 или 4 октета)

0x03 (Q.922 Control)

NLPID 0x81

. Остальная часть CLNP PD .

Отметим, что для протоколов ISO поле NLPID формирует первый октет PDU и не должно повторяться.

Описанная выше инкапсуляция применима только к тем из маршрутизируемых протоколов, которые имеют уникальный идентификатор NLPID. Для остальных маршрутизируемых протоколов (и для протоколов, использующих мосты) требуется обеспечить иной механизм простой идентификации протокола. Для решения этой задачи можно использовать значение NLPID = 0x80, чтобы указать следующий далее заголовок IEEE 802.1a SNAP.

Детальное описание многопротокольной инкапсуляции поверх FRCS приведено в RFC 2427.

Приложение B. Список локально распределяемых OUI 00-80-C2

С сохранением FCS	Без сохранения FCS	Среда
0x00-01	0x00-07	802.3/Ethernet
0x00-02	0x00-08	802,4
0x00-03	0x00-09	802,5
0x00-04	0x00-0A	FDDI
0x00-05	0x00-0B	802,6
	0x00-0D	Фрагменты
	0x00-0E	BPDU

Приложение C. Частичный список NLPID

0x00    Null Network Layer или Inactive Set (не используется с ATM)
0x80    SNAP
0x81    ISO CLNP
0x82    ISO ESIS
0x83    ISO ISIS
0xCC    Internet IP

Приложение D. Применение многопротокольной инкапсуляции

Мультипротокольная инкапсуляция необходима (но, в общем случае, недостаточна) для маршрутизации и организации мостов через сети ATM. С момента публикации RFC 1483 (предшественник данного документа) IETF и ATM Forum подготовили несколько спецификаций по различным аспектам маршрутизации и организации мостов. В этом приложении содержится краткий список таких спецификаций.

1. Point-to-point connection between routers and bridges — многопротокольная инкапсуляция поверх ATM PVC используется для организации простых каналов “точка-точка” между мостами и маршрутизаторами через сеть ATM. Для этого сценария требуется выполнять некоторое количество настроек вручную (например, INARP).

2. Classical IP over ATM — RFC 2225⁵ (первоначальный вариант — RFC 1577) обеспечивает среду, где сеть ATM выступает в качестве логической подсети IP (LIS). Поддерживаются ATM PVC с преобразованием адресов на основе INARP. Для ATM SVC используется ATMARP (новая форма ARP), обеспечивающая взаимодействие через сеть ATM между хостом (или маршрутизатором) и сервером ATMARP. При использовании репликации сервера для повышения надежности и производительности применяется протокол SCSP (Server Synchronization Cache Protocol — протокол синхронизации серверных кэшей), определенный в RFC 2335. Classical IP over ATM по умолчанию использует инкапсуляцию LLC/SNAP.

3. LAN Emulation — Спецификация эмуляции ЛВС ATM Forum обеспечивает среду, где возможности ATM расширяются за счет использования серверов LAN Emulation, работающих как локальные сети на основе мостов (bridged LAN). Станции получают конфигурационные параметры и регистрируются на сервере LECS (LAN Emulation Configuration Server); MAC-адреса преобразуются в адреса ATM с помощью служб сервера эмуляции ЛВС и станции могут передавать пакеты с широковещательными (broadcast) и групповыми (multicast) адресами, а также пакеты для индивидуальных адресов (unicast), не связанных явно с VC, специальному серверу широковещания (Broadcast and Unicast Server). LANE использует мультиплексирование VC для инкапсуляции кадров Bridged Etherent/802.3 (без LAN FCS) или Bridged 802.5 (без LAN FCS) для Data Direct, LE Multicast Send и Multicast Forward VCCS. Однако, изначальное поле заполнения PAD, описанное в данном документе, используется как заголовок LE и не должно состоять из одних нулей.

4. Next Hop Resolution Protocol (NHRP) — В некоторых случаях ограничения Classical IP over ATM (поддержка единственного LIS) ведут к снижению производительности. Протокол NHRP, описанный в RFC 2332, расширяет возможности Classical IP over ATM, позволяя работать с несколькими LIS.

5. Multiprotocol over ATM (MPOA) — Спецификация ATM Forum MPOA объединяет возможности LANE и NHRP для обеспечения базовой среды с поддержкой маршрутизации и мостов.

6. IP Multicast — RFC 2022 расширяет возможности Classical IP за счет поддержки IP multicast (групповая адресация). Сервер преобразования групповых адресов MARS может использоваться совместно с multicast-сервером для рассылки по групповым адресам IP через сеть ATM с использованием виртуальных соединений point-to-multipoint и/или point to point.

7. PPP over ATM — RFC 2364 расширяет возможности многопротокольной инкапсуляции поверх ATM для использования протокола PPP. В этом расширении используется как мультиплексирование VC, так и инкапсуляция LLC/SNAP. Это расширение обычно используется в сетях ATM с соединениями “точка-точка” для поддержки протокола PPP.

Приложение E. Отличия от RFC 1483

Этот документ заменяет RFC 1483. Документ избавлен от анахронизмов, устраняет неоднозначности, обнаруженные в ранних реализациях и расширяет возможности протокола с учетом стандартов IETF. Было сделано также множество редакторских правок с учетом соглашений RFC 2119 [10]. Ниже перечислены основные изменения, внесенные в документ. Ни одно из этих изменений не должно противоречить реализациям RFC 1483:

• использование инкапсуляции NLPID описано с учетом соглашений RFC 2119;
• добавлена ссылка на RFC 2364 (PPP over ATM);
• включены ссылки на RFC 1755 и RFC 2331, описывающие согласование инкапсуляции взамен давно устаревших рабочих документов CCITT (не ITU-T);
• использование AAL5 описано на основе ITU-T I.363.5 (эта опция AAL5 была создана после публикации RFC 1483);
• внесена ясность в форматирование маршрутизируемых NLPID PDU (routed ISO PDU в RFC 1483);
• внесена ясность в использование заполнения для PID и MAC-адресов получателей для PDU с использованием мостов, а также порядок битов для MAC-адресов;
• внесена ясность в использование заполнения для кадров Ethernet/802.3;
• добавлена инкапсуляция для VPN;
• добавлено рассмотрение вопросов безопасности;

• в новом приложении D приведено резюме использования многопротокольной инкапсуляции поверх ATM.

Адреса авторов

Dan Grossman
Motorola, Inc.
20 Cabot Blvd.
Mansfield, MA 02048

EMail: dan@dma.isg.mot.com

Juha Heinanen
Telia Finland
Myyrmaentie 2
01600 Vantaa, Finland

EMail: jh@telia.fi

---

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (1999). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

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

Подтверждение

Финансирование функций RFC Editor обеспечивалось Internet Society.

5Эта спецификация обновлена в RFC 5494. Прим. перев.