RFC 1242 Benchmarking Terminology for Network Interconnection Devices

Network Working Group                             S. Bradner, Editor
Request for Comments: 1242                        Harvard University
                                                           July 1991

Терминология тестирования производительности устройств объединения сетей

Benchmarking Terminology for Network Interconnection Devices

PDF

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

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

Тезисы

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

1. Введение

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

2. Формат определения

Определяемый термин (например, задержка — Latency).

Определение

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

Обсуждение

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

Единицы измерения

Единицы, используемые в отчетах для данного термина, если таковые применимы.

Проблемы

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

Дополнительная информация

Список других терминов и вопросов, связанных с данным.

3. Определения терминов

3.1 Back-to-back

Определение

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

Обсуждение

Рост числа устройств в сети может приводить к пикам кадров back-to-back. Удаленные дисковые серверы, использующие протоколы типа NFS, удаленные дисковые системы резервного копирования типа rdump и удаленные системы хранения на магнитной ленте могут быть настроены таким образом, что по одному запросу может возвращаться блок данных размером более 64 кбайт. В сетях типа Ethernet с относительно малым значением MTU это может приводить к передаче множества фрагментов. Поскольку сборка фрагментов будет осуществляться только по завершении приема всех фрагментов, потеря даже одного фрагмента в результате отказа на том или ином промежуточном сетевом устройстве при обработке непрерывного потока кадров может приводить к зацикливанию процесса передачи большого блока данных.

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

Единицы измерения

Число N-октетных кадров в пике.

Проблемы

Дополнительная информация

3.2 Мост (Bridge)

Определение

Система, пересылающая кадры данных на основе информации канального уровня (data link layer).

Обсуждение

Единицы измерения

нет

Проблемы

Дополнительная информация

3.3 Мост/маршрутизатор (Bridge/router)

3.15 Маршрутизатор (Router)

3.3 Мост/маршрутизатор (Bridge/router)

Определение

Сетевое устройство, которое может работать как мости и/или маршрутизатор в зависимости от протокола конкретного кадра.

Обсуждение

Единицы измерения

нет

Проблемы

Дополнительная информация

3.2 Мост (Bridge)

3.15 Маршрутизатор (Router)

3.4 Постоянная нагрузка (Constant Load)

Определение

Передача кадров фиксированного размера с фиксированным интервалом.

Обсуждение

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

Единицы измерения

нет

Проблемы

Сравнение одностороннего и двухстороннего потоков кадров.

Дополнительная информация

3.5 Размер кадра канального уровня (Data link frame size)

Определение

Число октетов, начиная с первого октета после преамбулы и заканчивая FCS (при наличии) или последним октетом данных, если FCS не используется.

Обсуждение

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

Единицы измерения

Октеты

Проблемы

Дополнительная информация

3.6 Частота потери кадров (Frame Loss Rate)

Определение

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

Обсуждение

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

Единицы измерения

Процент отбрасываемых N-октетных кадров. Обычно представляется в форме графика зависимости потерь от нагрузки.

Проблемы

Дополнительная информация

3.11 Влияние дополнительных задач (Overhead behavior)

3.13 Фильтрация на основе правил (Policy based filtering)

3.10 Поведение при несоответствии MTU (MTU-mismatch behavior)

3.7 Межкадровый интервал (Inter Frame Gap)

Определение

Интервал времени между окончанием кадра канального уровня (см. параграф 3.5) и началом преамбулы следующего кадра канального уровня.

Обсуждение

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

Единицы измерения

Время с точностью, достаточной для того, чтобы различить 2 события.

Проблемы

Скорость на канальном уровне.

Дополнительная информация

3.8 Задержка (Latency)

Определение

Для устройств с промежуточной буферизацией (store and forward):

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

Для устройств без промежуточной буферизации (bit forwarding):

Временной интервал между окончанием приема первого бита кадра во входном порту и началом передачи первого бита кадра в выходном порту.

Обсуждение

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

В идеальном случае измерения для всех устройств будут начинаться с первого бита кадра после преамбулы. Теоретически производители могут создавать устройства, которые в обычных условиях будет считаться устройствами с промежуточной буферизацией (например, мостами), но на практике будут начинать передачу до того, как кадр будет принят полностью3. Для обозначения этого типа устройств используется термин cut through. Предполагается, что такое устройство будет каким-то способом заявлять о некорректности кадра, для которого были обнаружены ошибки (например, некорректна контрольная сумма) после того, как передача кадра уже началась. В таких случаях устройство следует рассматривать, как store and forward и задержку в нем следует по-прежнему измерять от последнего бита на входе до первого бита на выходе, что будет давать отрицательные значения. Смысл этого состоит в том, чтобы устройство рассматривалось, как целое, без учета внутренней структуры.

Единицы измерения

Время с точностью, достаточной для того, чтобы различить 2 события.

Проблемы

Дополнительная информация

3.9 Несоответствие скоростей канала (Link Speed Mismatch)

3.4 Постоянная нагрузка (Constant Load)

3.1 Back-to-back

3.13 Фильтрация на основе правил (Policy based filtering)

3.16 Поведение одиночного кадра (Single frame behavior)

3.9 Несоответствие скоростей канала (Link Speed Mismatch)

Определение

Рассогласование входной и выходной скоростей.

Обсуждение

Это не относится к скорости передачи кадров, как таковой, и связано с реальной скоростью передачи кадров в пути обмена данными. Например, с одной стороны имеется Ethernet, а с другой последовательная линия 56K. Это называют также «эффектом пожарного шланга» (fire hose effect). Сети, использующие последовательные каналы между скоростными ЛВС, обычно сталкиваются с несоответствием скоростей на каждой стороне последовательного канала.

Единицы измерения

Отношение входной и выходной скоростей.

Проблемы

Дополнительная информация

3.4 Постоянная нагрузка (Constant Load)

3.1 Back-to-back

3.10 Поведение при несоответствии MTU (MTU-mismatch behavior)

Определение

Значение MTU4 в выходной сети меньше MTU во входной сети, что ведет к фрагментации.

Обсуждение

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

Единицы измерения

Описание поведения.

Проблемы

Дополнительная информация

3.11 Влияние дополнительных задач (Overhead behavior)

Определение

Обработка выполняется иначе, нежели для нормальных кадров.

Обсуждение

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

Единицы измерения

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

Проблемы

протоколы мостов и маршрутизаторов

выполнение управляющих функций

icmp

обработка опций ip

фрагментация

обработка ошибок

сбор и обработка статистики/протоколирования работы

arp

Дополнительная информация

3.13 Фильтрация на основе правил (Policy based filtering)

3.12 Поведение при перегрузке (Overloaded behavior)

Определение

Ситуации когда потребности превосходят доступные системные ресурсы.

Обсуждение

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

Единицы измерения

Описание поведения устройства во всех состояниях перегрузки по входам или выходам.

Проблемы

Как устройство выходит из состояния перегрузки?

Как на устройство воздействует «подавление отправителя» (source quench)?

Что делает устройство при исчерпании его ресурсов?

Как система управления устройством реагирует на перегрузку?

Дополнительная информация

3.13 Фильтрация на основе правил (Policy based filtering)

Определение

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

Обсуждение

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

Единицы измерения

нет

Проблемы

гибкость опций фильтрации

число условий в фильтре

Дополнительная информация

3.14 Поведение при перезапуске (Restart behavior)

Определение

Перезапуск системы приводит к потере данных.

Обсуждение

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

Единицы измерения

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

Проблемы

Типы перезапуска:

по питанию

перезагрузка программного образа

сбрасывание портов и буферов

перезапуск текущей копии программного образа без изменения конфигурации

При каких условиях требуется перезапуск?

Знает ли устройство о необходимости перезапуска(например, тайм-аут при «зависании»)?

Способно ли устройство зафиксировать слишком частые перезапуски?

Используется ли диагностика устройства при всех или некоторых вариантах перезапуска?

Как можно инициировать перезапуск?

непосредственный доступ

удаленный доступ по терминальной линии или через сеть

Дополнительная информация

3.15 Маршрутизатор (Router)

Определение

Система, пересылающая кадры данных на основе информации сетевого уровня.

Обсуждение

Это предполагает наличие работающего алгоритма маршрутизации сетевого уровня и выполнение требуемых протоколом действий (например, уменьшение значения поля TTL в заголовке TCP/IP).

Единицы измерения

нет

Проблемы

Дополнительная информация

3.2 Мост (Bridge)

3.3 Мост/маршрутизатор (Bridge/router)

3.16 Поведение одиночного кадра (Single frame behavior)

Определение

На вход устройства поступает одиночный кадр.

Обсуждение

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

Единицы измерения

Описание поведения устройства.

Проблемы

Дополнительная информация

3.13 Фильтрация на основе правил (Policy based filtering)

3.17 Пропускная способность (Throughput)

Определение

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

Обсуждение

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

Единицы измерения

Число N-октетных кадров в секунду

Скорость на входе в бит/с

Проблемы

Один путь в сравнении с агрегатным

Загрузка

Односторонний и двухсторонний поток данных

Обработка контрольных сумм для применяющих их протоколов

Дополнительная информация

3.6 Частота потери кадров (Frame Loss Rate)

3.4 Постоянная нагрузка (Constant Load)

3.1 Back-to-back

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

Этот документ является результатом работы группы IETF BMWG в составе:

Chet Birger, Coral Networks

Scott Bradner, Harvard University (председатель)

Steve Butterfield, независимый консультант

Frank Chui, TRW

Phill Gross, CNRI

Stev Knowles, FTP Software, Inc.

Mat Lew, TRW

Gary Malkin, FTP Software, Inc.

K.K. Ramakrishnan, Digital Equipment Corp.

Mick Scully, Ungerman Bass

William M. Seifert, Wellfleet Communications Corp.

John Shriver, Proteon, Inc.

Dick Sterry, Microcom

Geof Stone, Network Systems Corp.

Geoff Thompson, SynOptics

Mary Youssef, IBM

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

Вопросы безопасности не рассматриваются в этом документе.

Адрес автора

Scott Bradner

Harvard University

William James Hall 1232

33 Kirkland Street

Cambridge, MA 02138

Phone: (617) 495-3864

EMail: SOB@HARVARD.HARVARD.EDU

Можно отправлять комментарии по адресу bmwg@harvisr.harvard.edu.


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

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

nmalykh@protocols.ru

1Benchmarking Methodology Working Group

2Internet Engineering Task Force

3Таких устройств сейчас выпускается достаточно много. Прим. перев.

4Maximum Transmission Unit — максимальный размер передаваемого блока.




RFC 1241 A Scheme for an Internet Encapsulation Protocol: Version 1

Network Working Group                                    R. Woodburn
Request for Comments: 1241                                      SAIC
                                                            D. Mills
                                              University of Delaware
                                                           July 1991

Схема для протокола инкапсуляции Internet (версия 1)

A Scheme for an Internet Encapsulation Protocol:

Version 1

PDF

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

Этот документ определяет экспериментальный протокол для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из документа IAB Official Protocol Standards. Документ может распространяться без ограничений.

2. Глоссарий

Clear Datagram — исходная (чистая) дейтаграмма

Неизмененная дейтаграмма IP в Пользовательском Пространстве (User Space) до Инкапсуляции.

Clear Header — исходный заголовок

Заголовочная часть Исходной Дейтаграммы (Clear Datagram) до Инкапсуляции. Этот заголовок включает заголовок IP, а также может включать часть или все заголовки протокола следующего уровня (например, заголовок TCP).

Decapsulation — декапсуляция

Отбрасывание Заголовка Инкапсуляции (Encapsulation Header) и пересылка чистой дейтаграммы Декапсулятором.

Decapsulator — декапсулятор

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

Encapsulated Datagram — инкапсулированная дейтаграмма

Дейтаграмма, содержащая Исходную Дейтаграмму (Clear Datagram) и добавленный перед ней Заголовок Инкапсуляции.

Encapsulation — инкапсуляция

Процесс отображения Исходной Дейтаграммы в Пространство Инкапсуляции (Encapsulation Space) добавление перед дейтаграммой Заголовка Инкапсуляции и маршрутизация инкапсулированной дейтаграммы Декапсулятору.

Encapsulation Header — заголовок инкапсуляции

Заголовок для Протокола Инкапсуляции, помещаемый перед Исходной Дейтаграммой в процессе Инкапсуляции. Этот заголовок включает заголовок IP, за которым следует Заголовок Протокола Инкапсуляции .

Encapsulation Protocol Header — заголовок протокола инкапсуляции

Определяемая Протоколом Инкапсуляции часть Заголовка Инкапсуляции.

Encapsulation Space — пространство инкапсуляции

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

Encapsulator — инкапсулятор

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

Flow — поток

Поток или туннель (tunnel) представляет собой сквозной (end-to-end) путь в Пространстве Инкапсуляции, по которому передаются Инкапсулированные Дейтаграммы. Вдоль одного туннеля (потока) может размещаться несколько пар Инкапсулятор-Декапсулятор. Отметим, что поток не обязан включать шлюзы (маршрутизаторы) Пользовательского Пространства.

Flow ID — идентификатор потока

32-битовое значение, позволяющее уникально идентифицировать поток (туннель) в данном Инкапсуляторе/Декапсуляторе. Идентификаторы потоков специфичны для Инкапсулятора/Декапсулятора и не являются глобальными.

Mapping Function — функция отображения

Это функция, отображающая Исходную Дейтаграмму на конкретный Поток (туннель). Все Инкапсуляторы одного Потока должны отображать данную Исходную Дейтаграмму на один Поток.

User Address — адрес пользователя

Адрес или идентификатор, позволяющий уникально определить объект в Пользовательском Пространстве.

Source Route — маршрут, заданный отправителем

Полный сквозной маршрут, рассчитанный на стороне отправителя и включающий все транзитные маршрутизаторы.

User Space — пользовательское пространство

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

3. Предпосылки

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

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

                    ++++++  Исходная Дейтаграмма
                    ******  Инкапсулированная Дейтаграмма
                         #  Инкапсулятор/Декапсулятор
                         &  Хост Пользовательского Пространства

   Пользовательское                Пользовательское
   Пространство A                  Пространство C
   --------------                  ------------
  /              \                /           \
 /                \              /             \
|                  |            |               |
|     &            |            |               |
|     +   +++++    |            |       *****   |
|     +++++   +    |            |       *   *   |
|             +    |            |   *****   *   |
 \            +   / ----------- \   *       *   / -----------
  \           ++> # *         **> # *       ***> # ++++      \
   --------------  / *        *  \ ------------  /    +       \
                  |  *        *   |             |     +        |
                  |  *        *   |             |     +        |
                  |  *****    *   |             |     +++++++  |
                  |      *****    |             |           V  |
                  |               |             |           &  |
                   \             /               \             /
                    \           /                 \           /
                     -----------                   -----------
                     Пространство               Пользовательское
                     Инкапсуляции D             Пространство D

Рисунок 1 Модель архитектуры инкапсуляции

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

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

До настоящего времени не существовало стандарта для протокола инкапсуляции. Этот документ предлагает механизм инкапсуляции в среде Internet.

4. Архитектура и модель

Архитектура инкапсуляции основана на двух базовых элементах — Инкапсуляторах и Декапсуляторах. Эти элементы и связанные с ними пространства показаны на рисунке 1.

Инкапсуляторы и декапсуляторы имеют адреса с Пользовательских Пространствах, к которым они относятся, а также адреса в Пространствах Инкапсуляции, к которым они принадлежат. Инкапсулятор будет получать Исходную Дейтаграмму (Clear Datagram) из своего Пользовательского Пространства и, после определения необходимости использования инкапсуляции, выполнять функцию отображения, которая транслирует информацию Пользовательского Пространства из Исходного Заголовка в Заголовок Инкапсуляции. Созданный Заголовок Инкапсуляции помещается перед Исходной Дейтаграммой для формирования Инкапсулированной Дейтаграммы, как показано на рисунке 2. Желательно обеспечить прозрачность процесса инкапсуляции для объектов Пользовательского Пространства. Знать об инкапсуляции должны только Инкапсуляторы.

+---------------+-------------------+---------+--------------------+
|Инкапсулирующий|Заголовок Протокола|Исходный |Остальная часть     |
| Заголовок IP  | Инкапсуляции      |Заголовок|Исходной Дейтаграммы|
+---------------+-------------------+---------+--------------------+ 

|                                   |                              |
|        Заголовок Инкапсуляции     |      Исходная Дейтаграмма    |
|                                   |                              |

Рисунок 2 Пример Инкапсулированной Дейтаграммы

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

5. Генерация Заголовка Инкапсуляции

                                            +--------+
                                            |        |
                                         +->| Таблица|--+
                                         |  | данных |  |
               +-------+                 |  | инкапс.|  |
               | Маска |   +---------+   |  |        |  |
Исходный --+-->| и соот|-->| Flow ID |---+  |        |  |
Заголовок  |   | ветств|   +---------+      +--------+  |
           |   +-------+                                |
           |                                            +--> Заголовок
           +-----------------------------------------------> Инкапсуляции

Рисунок 3 Генерация Заголовка Инкапсуляции

Содержимое Заголовка Инкапсуляции генерируется путем отображения Исходного Заголовка. Функция отображения может быть реализована по разному, но результат должен быть один и тот же. Процесс генерации показан на рисунке 3.

На первом этапе отображения функция сравнивает Исходный Заголовок с сохраненными заголовками и масками для определения идентификатора потока Flow ID. По сути, этот этап заключается в просмотре таблицы «масок и соответствий» (mask-and-match), содержащей записи из трех элементов — Исходный Заголовок, маска заголовка и соответствующий идентификатор туннеля (Flow ID). Маска может использоваться для определения диапазонов адресов отправителей и получателей, чьи пакеты будут отображаться в данный поток (туннель). Для разделения потоков могут использоваться и другие поля типа битов IP TOS или номеров портов TCP для отправителя и получателя. Такая гибкость обеспечивает многочисленные возможности применения функции отображения. С туннелем можно связать не только заданную сеть, но конкретный протокол TCP или соединение.

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

Идентификаторы туннелей (Flow ID) также обрабатываются на вышележащем уровне. Пример обработки Flow ID можно найти в протоколе Setup протокола IDPR1 [4]. Протокол вышележащего уровня будет отвечать за поддержку информации, которая не передается в протоколе инкапсуляции, связанном с туннелем. Эта информация может включать данные, требуемые для создания Заголовка Инкапсуляции (см. ниже), а также сведения о типе инкапсулируемых данных (в настоящее время только IP) и типе используемой аутентификации. Отметим, что протокол IDPR Setup требует использования более длинных идентификаторов Flow ID для обеспечения уникальности в масштабе всего множества Инкапсуляторов.

Значение Flow ID, получаемое в результате отображения Clear Header, представляет собой 32-битовое число, которое идентифицирует туннель (Flow) с точки зрения Инкапсулятора. Если Исходную Дейтаграмму в процессе доставки адресату требуется инкапсулировать и декапсулировать неоднократно, значения Flow ID могут различаться на каждом Инкапсуляторе, но это не обязательно. Значение Flow ID служит индексом для таблицы с информацией о Заголовках Инкапсуляции, которая используется для генерации этих заголовков. Отметим, что решение о локальной значимости значений Flow ID для каждого Инкапсулятора было принято с учетом сложностей, возникающих при выборе и поддержке идентификаторов глобальной значимости.

Промежуточный этап использования Flow ID является сугубо опциональным. Важным требованием является использование всеми Инкапсуляторами на пути доставки одного Исходного Заголовка (Clear Header) в рамках одного туннеля Flow (сам туннель вдоль пути может иметь разные идентификаторы). Тем не менее, учет значения Flow ID в протоколе позволяет более эффективно реализовать функцию отображения. Этот вопрос более подробно рассматривается ниже при описании Декапсулятора.

Для создания Заголовка Инкапсуляции требуется следующая информация:

Flow ID — идентификатор туннеля

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

Decapsulator Address — адрес получателя

IP-адрес Декапсулятора и Пространстве Инкапсуляции, требуемый для построения IP-части Заголовка Инкапсуляции.

Decapsulator’s Flow ID — идентификатор потока на стороне декапсулятора

Значение Flow ID (при его наличии) для потока Flow с точки зрения Декапсулятора.

Previous Encapsulator’s Address — адрес предыдущего инкапсулятора

Если данный Инкапсулятор не является первым в туннеле Flow, адрес предыдущего Инкапсулятора требуется для передачи сообщений об ошибках.

Previous Encapsulator’s Flow ID — идентификатор туннеля на предыдущем инкапсуляторе

В дополнение к адресу предыдущего Инкапсулятора должно быть известно значение Flow ID для туннеля Flow относительно предыдущего Инкапсулятора.

Заголовок Инкапсуляции состоит из заголовка IP (IP Header) и заголовка протокола инкапсуляции (Encapsulation Protocol Header). Во время инкапсуляции должны быть определены две части Заголовка Протокола Инкапсуляции — инкапсулируемый протокол и значение Flow ID для передачи Декапсулятору. Генерация заголовка IP более сложна.

Для каждого поля Исходного Заголовка возможны две операции при создании нового заголовка IP:

Копировать

Существующее поле Исходного Заголовка копируется в заголовок IP Заголовка Инкапсуляции.

Игнорировать

Это поле может присутствовать в Исходном Заголовке, но оно не применимо для нового заголовка IP.

Таблица 1 Отображение полей заголовка IP

Поле Операция
Version Игнорировать
Header Length Игнорировать
Precedence Копировать
Биты QoS Копировать
Total Length Игнорировать
Identification Игнорировать
Флаг Don’t Fragment Игнорировать
Флаг More Fragments Игнорировать
Fragment Offset Игнорировать
Time to Live Игнорировать
Protocol Игнорировать
Header Checksum Игнорировать
Source Address Игнорировать
Destination Address Игнорировать
End of Option List Игнорировать
Опция NOP Игнорировать
Опция Security Копировать
Опция LSR Игнорировать
Опция SSR Игнорировать
Опция RR Игнорировать
Опция Stream ID Игнорировать
Опция Timestamp Игнорировать

Заголовок IP имеет фиксированную и переменную (список опций) часть. Список всех полей заголовка IP и связь их с полями Исходного Заголовка приведены в таблице 1 [2].

Отметим, что большинство полей Исходного Заголовка просто игнорируется. Например, поле Header Length в Исходном Заголовке не определяет значение поля Header Length в новом заголовке IP. Далее будут рассматриваться поля, которые более интересны и могут копироваться в новый заголовок.

Биты качества обслуживания (QoS2) следует копировать из Исходного Заголовка в новый заголовок IP. Это делается из соображений прозрачности, чтобы услуги, предоставляемые в Пользовательском Пространстве, обеспечивались и в Пространстве Инкапсуляции.

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

Флаг Don’t Fragment не следует копировать в Заголовок Инкапсуляции. Здесь снова будет нарушаться принцип прозрачности. Решение вопроса о запрете фрагментации в Пространстве Инкапсуляции следует предоставить Инкапсулятору. Если Инкапсулятор решит установить флаг DF, при возникновении необходимости фрагментации Инкапсулированной Дейтаграммы в Пространстве Инкапсуляции ему должно быть возвращено сообщение ICMP. Однако в этом случае будет меняться механизм возврата сообщения ICMP отправителю в Пользовательское Пространство, как это описано в Приложении B.

Относительно поля времени жизни (TTL) самым простым решением будет игнорирование значения этого поля в Исходном Заголовке. Если это поле копировать из Исходного Заголовка в новый заголовок IP, жизнь пакета может завершиться преждевременно в процессе передачи через Пространство Инкапсуляции. Это нарушит принцип прозрачности инкапсуляции с точки зрения Пользовательского Пространства. Значение TTL из Исходного Заголовка будет уменьшено перед инкапсуляцией функцией пересылки IP, следовательно не возникает предпосылок зацикливания пакетов в случае замыкания туннеля Flow в петлю.

В поле протокола для нового заголовка IP следует указывать номер протокола инкапсуляции.

В качестве адреса отправителя в новом заголовке IP используется IP-адрес Инкапсулятора в Домене Инкапсуляции. В качестве адреса получателя указывается IP-адрес Декапсулятора из таблицы инкапсуляции.

Опции IP в общем случае не копируются, поскольку они не имеют смысла в контексте Пространства Инкапсуляции. Опция безопасности (Security) является, возможно, единственным исключением из этого правила и ее следует копировать по тем же причинам, которые требуют копирования полей QOS и Precedence (Пространство Инкапсуляции должно обеспечивать ожидаемый сервис). Опции Timestamp, Loose Source Route, Strict Source Route и Record Route не копируются при инкапсуляции.

6. Декапсуляция

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

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

Поскольку при использовании Flow ID нормальный механизм пересылки IP обходится, некоторые операции, обычно выполняемые IP, должны быть реализованы Декапсулятором перед инкапсуляцией. Декапсулятор должен уменьшить значение поля TTL перед выполнением следующей инкапсуляции. При возникновении ошибки Time Exceeded3 отправителю, указанному в Исходном Заголовке должно быть передано сообщение ICMP.

7. Сообщения об ошибках

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

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

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

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

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

[1] J. Postel, Internet Control Message Protocol, RFC 7924, September 1981.

[2] J. Postel, Internet Protocol, RFC 7912, September 1981.

[3] J. Postel, Transmission Control Protocol, RFC 7932, September 1981.

[4] ORWG, Inter-Domain Policy Routing Protocol Specification and Usage, Draft5, August 1990

 0               8              16              24             31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers  |   HL  |  MT   |  RC   |            Checksum           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Flow ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок A.1. Пример Заголовка Инкапсуляции

A. Формат пакетов

В этом приложении описан формат пакетов протокола инкапсуляции.

Vers 4 бита

Номер версии протокола инкапсуляции. Для описываемого в данном документе протокола используется значение 1.

HL 4 бита

Размер Заголовка Протокола Инкапсуляции (Encapsulation Protocol Header) в октетах.

MT 4 бита

Тип сообщения Протокола Инкапсуляции. Для сообщений с данными (Data Message) указывается тип 1, для сообщений об ошибках — тип 2.

RC 4 бита

Код причины. Это поле не используется в сообщениях с данными Data Message и должно иметь значение 0. В сообщениях об ошибках код указывает причину генерации сообщения:

1 Unknown Flow ID — неизвестный идентификатор туннеля;

2 ICMP returned — возврат сообщения ICMP.

Checksum 16 битов

Контрольная сумма (дополнение до 1) для Заголовка Протокола Инкапсуляции. При расчете для поля устанавливается значение 0, а рассчитанное значение помещается в это поле до передачи сообщения.

Flow ID 32 бита

Идентификатор туннеля Flow ID с точки зрения Декапсулятора или Инкапсулятора, которому будет отправлено сообщение. При передаче сообщений об ошибках Unknown Flow ID используется значение идентификатора, вызвавшего ошибку.

Для сообщений с данными после Заголовка Протокола Инкапсуляции следует Исходная дейтаграмма (Clear Datagram). Для сообщений об ошибках после заголовка следует сообщение ICMP, передаваемое по туннелю.

B. Инкапсуляция и существующие механизмы IP

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

B.1 Фрагментация и MTU

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

Фрагментация на промежуточных шлюзах (маршрутизаторах) Пользовательского Пространства создает другую проблему. Фрагментация происходит на уровне IP. Если используется протокол TCP и возникает фрагментация, заголовок TCP будет присутствовать только в первом фрагменте [3]. Если эти фрагменты пересылаются Инкапсулятором, распознавание Исходного Заголовка (Clear Header) для данного туннеля будет возможно только для IP-части. При попыке распознать TCP-часть заголовка, соответствие будет найдено только для первого фрагмента, а остальные фрагменты не будут отнесены к данному туннелю.

B.2 Сообщения ICMP

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

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

В данной спецификации идентификатор туннеля Flow ID рассматривается, как уникальный способ одностороннего отображения Исходного Заголовка. Нет гарантии возможности использования Flow ID для обратного отображения на Исходный Заголовок, поскольку на один поток может быть отображено множество разных заголовков. Поскольку эффективного способа восстановления исходной дейтаграммы не существует, требуется проверить несколько компромиссных вариантов.

Для каждого из возможных сообщений ICMP будут оценены варианты и последствия. Рассматриваются три категории сообщений ICMP. К первой категории отнесены сообщения ICMP, не применимые в контексте Инкапсуляции (Echo/Echo Reply и Timestamp/Timestamp Reply).

Вторая категория включает сообщения ICMP, относящиеся к локальным механизмам области инкапсуляции. Есть сообщения, которые не будут иметь никакого смысла для исходного отправителя, даже если он их получит. В таких случаях инкапсулятор принимает решение самостоятельно, но передавать какие-либо сообщения ICMP исходному отправителю не требуется. Дейтаграмма просто теряется — протокол IP не гарантирует доставки. Последующие сообщения, полученные для инкапсуляции, могут заставить инкапсулятор генерировать сообщения ICMP Destination Unreachable для исходного отправителя, если инкапсулятор больше не может передавать сообщения декапсулятору адресата. Для этого нужно, чтобы сообщения ICMP в области инкапсуляции оказывали влияние на отображение из Flow ID. К сообщениям ICMP второй категории относятся: Parameter Problem, Redirect, Destination Unreachable, Time Exceeded.

К третьей категории относится сообщение ICMP, которое оказывает непосредственное воздействие на работу исходного отправителя, — ICMP Source Quench. Для Инкапсулятора единственным возможным механизмом обработки таких сообщений является установка для соответствующего Flow ID такого флага, который потребует генерации сообщений ICMP Source Quench исходному отправителю до инкапсуляции его дейтаграмм.

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

C. Прием Исходных Дейтаграмм

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

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

На последнем Декапсуляторе пакета требуется способ корректной передачи декапсулированных дейтаграмм модулю IP для доставки. Поскольку пакеты инкапсулируются непосредственно перед пересылкой, для декапсулированных дейтаграмм нужен простой метод вставки дейтаграм на выход IP. Однако адрес отправителя в Исходном Заголовке менять недопустимо. Адрес должен указывать на отправителя в Пользовательском Пространстве и не переписывается на адрес Декапсулятора.

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

                         ++++++ Виртуальная сеть A
                         ****** Виртуальная сеть B
                              # Инкапсулятор/Декапсулятор
                         ------ Общее пространство маршрутизации
  -------------                     -----------
 /             \                   /           \
/       +++ #   \                 /             \
|  # +++    +    |               |    # ***** #  |
|  +        +    |               |    *       *  |
|  +       +     |               |     *     *   |
|   +      +     |               |      *   *    |
|   # ++++ # +   |               |       * *     |
\             + /  -------------  \       # ** /   ---------
 \            + # ++            \ # ******   *** # **        \
  ------------   /  +++          *  ------------  /   ***      \
                |      #        * |              |       # *** #|
                |      +      **  |              |       *     *|
                |      +     #    |              |      *    ** |
                |      + ++++ *   |              |     *    *   |
                |       #+     *  |              |    *    *    |
     ----------  \ ++++         */  ------------  \  *    #    /
    /          \ # +             # **           * # *****    /
   /            +  ------------- /   # ****** # *\   --------
  | # +++++++   +|              |    *        *   |
  | +        + + |              |    *         *  |
  |  +         # |              |    *          * |
  |  +       ++  |              |    *          # |
  |  # ++++++    |              |    * *********  |
  \             /                \    #          /
   \           /                  \             /
    -----------                    ------------

Рисунок 4 Пример виртуальных сетей

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

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

С учетом сказанного, можно создать специальные шлюзы инкапсуляции с виртуальными интерфейсами в две виртуальных сети для формирования виртуальной «сети сетей» (virtual internet). Эту роль на рисунке играют Инкапсуляторы, соединяющие виртуальные сети A и B.

E. Инкапсуляция и OSI

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

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

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

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

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

Robert A. Woodburn

SAIC

8619 Westwood Center Drive

Vienna, VA 22182

Phone: (703) 734-9000 or (703) 448-0210

EMail: woody@cseic.saic.com

David L. Mills

Electrical Engineering Department

University of Delaware

Newark, DE 19716

Phone: (302) 451-8247

EMail: mills@udel.edu


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

Nikolai Malykh

nmalykh@gmail.com

1Inter-Domain Policy Sensitive Routing Protocol — протокол междоменной маршрутизации с учетом политики.

2Quality of Service.

3Время жизни истекло.

4Перевод этого документа доступен на сайте www.protocols.ru. Прим. перев.

5Работа была завершена и опубликована в RFC 1477, RFC 1478 и RFC 1479. Прим. перев.