RFC 2678 IPPM Metrics for Measuring Connectivity

Network Working Group                                        J. Mahdavi
Request for Comments: 2678             Pittsburgh Supercomputing Center
Obsoletes: 2498                                               V. Paxson
Category: Standards Track         Lawrence Berkeley National Laboratory
                                                         September 1999

IPPM Metrics for Measuring Connectivity

Показатели IPPM для измерения связности

PDF

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

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

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

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

1. Введение

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

Этот документ определяет серию показателей связности между парой хостов Internet. Документ основан на представлениях, введённых и рассмотренных в RFC 2330, описывающем схему IPPM. Предполагается знакомство читателя с этим документом.

Структура этого документа указана ниже.

• Аналитический показатель Type-P-Instantaneous-Unidirectional-Connectivity определяет одностороннюю связность в данный момент.

• С помощью этого показателя определяется метрика Type-P-Instantaneous-Bidirectional-Connectivity для двухсторонней связности в данный момент.

• С помощью показателей односторонней и двухсторонней связности определяется связность в интервале времени.

• С помощью этих показателей вводится аналитическая метрика Type-P1-P2-Interval-Temporal-Connectivity для обозначения двухсторонней связности между парой хостов в интервале времени.

• Представлены и рассмотрены методики оценки Type-P1-P2-Interval-Temporal-Connectivity в разных условиях.

Тщательное определение Type-P1-P2-Interval-Temporal-Connectivity и обсуждение этого показателя и методик его оценки являются основными частями данного документа.

2. Текущая связность в одном направлении

2.1. Имя показателя

Type-P-Instantaneous-Unidirectional-Connectivity

2.2. Параметры показателя

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

TT

Время.

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

Логическое значение (Boolean).

2.4. Определение

Src имеет мгновенную одностороннюю связность (Type-P-Instantaneous-Unidirectional-Connectivity) с Dst в момент времени T, если пакет type-P, переданный от Src к Dst в момент T, прибывает на хост Dst.

2.5. Обсуждение

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

Отметим, что момент прибытия пакета к Dst не определяется явно. Поле TTL в пакетах IP предназначено для ограничения срока действия пакета IP 255 секундами (RFC 791). На практике поле TTL может быть строгим счётчиком интервалов пересылки (hop, RFC 1812), который для большинства пересылок в Internet существенно короче секунды. Это означает, что большинство пакетов существует значительно меньше 255 секунд. Однако возможно существование пакета и дольше 255 секунд. Срок существования пакетов должен учитываться при попытках измерения этого показателя.

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

3. Двухсторонняя связность в данный момент

3.1. Имя показателя

Type-P-Instantaneous-Bidirectional-Connectivity

3.2. Параметры показателя

A1

IP-адрес хоста (источника).

A2

IP-адрес хоста (получателя).

T

Время.

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

Логическое значение (Boolean).

3.4. Определение

Адреса A1 и A2 имеют двухстороннюю связность (Type-P-Instantaneous-Bidirectional-Connectivity) в момент T, если для адреса A1 имеется односторонняя связность (Type-P-Instantaneous-Unidirectional-Connectivity) с адресом A2, а для адреса A2 имеется односторонняя связность с A1.

3.5. Обсуждение

Можно дать другое определение двухсторонней связности. Адреса A1 и A2 имеют полную связность, если в момент T адрес A1 имеет мгновенную связность с A2, а в момент T+dT адрес A2 имеет мгновенную связность с A1, при этом T+dT указывает момент прибытия пакета от A1 на адрес A2. Это определение более полезно для измерений, поскольку можно использовать отклик A2 по адресу A1 для оценки полной связности. Однако это определение сложнее из-за нарушения симметрии A1 и A2, а также необходимости оценки времени прохождения определённого пакета от A1 к A2. Дополнительно это различие обсуждается при описании метрики связности в интервале времени.

4. Односторонняя связность

4.1. Имя показателя

Type-P-Interval-Unidirectional-Connectivity

4.2. Параметры показателя

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

T

Время.

dT

Продолжительность

{Комментарий. [T, T+dT] указывает интервал времени.}

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

Логическое значение (Boolean).

4.4. Определение

Src имеет одностороннюю связность (Type-P-Interval-Unidirectional-Connectivity) в интервале времени [T, T+dT] с Dst, если для некого T’ из интервала [T, T+dT] имеется мгновенная связность (Type-P-instantaneous-connectivity) с Dst.

5. Двухсторонняя связность

5.1. Имя показателя

Type-P-Interval-Bidirectional-Connectivity

5.2. Параметры показателя

A1

IP-адрес хоста (источника).

A2

IP-адрес хоста (получателя).

T

Время.

dT

Продолжительность

{Комментарий. [T, T+dT] указывает интервал времени.}

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

Логическое значение (Boolean).

5.4. Определение

Между адресами A1 и A2 имеется двухсторонняя связность (Type-P-Interval-Bidirectional-Connectivity) в интервале времени [T, T+dT], если адрес A1 имеет одностороннюю связность (Type-P-Interval-Unidirectional-Connectivity) с адресом A2 в течение интервала и адрес A2 имеет одностороннюю связность с A1 в течение интервала времени.

5.5. Обсуждение

Этот параметр не совсем подходит в качестве определения «полезной в общем случае» связности и требует понимания, что пакет, переданный от A1 к A2 может вызвать отклик A2, который достигнет A1. При таком определении может случиться так, что A1 и A2 будут иметь полную связность, лишь в момент T1 в самом начале интервала [T, T+dT], когда A1 и A2 не могут ответить на пакет другой стороны. Для преодоления этого определён следующий показатель.

6. Временная двухсторонняя связность

6.1. Имя показателя

Type-P1-P2-Interval-Temporal-Connectivity

6.2. Параметры показателя

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

T

Время.

dT

Продолжительность

{Комментарий. [T, T+dT] указывает интервал времени.}

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

Логическое значение (Boolean).

6.4. Определение

Src имеет временную связность (Type-P1-P2-Interval-Temporal-Connectivity) с адресом Dst в интервале [T, T+dT], если существуют моменты времени T1 и T2, а также интервалы dT1 и dT2 такие, что выполняются условия:

• T1, T1+dT1, T2, T2+dT2 в диапазоне [T, T+dT];

• T1+dT1 <= T2;

• в момент T1 хост Src имеет мгновенную связность Type-P1 с Dst;

• в момент T2 хост Dst имеет мгновенную связность Type-P2 с Src;

• dT1 – время, когда пакет для Type-P1, переданный Src в момент T1, прибывает на Dst;

• dT2 – время, когда пакет для Type-P2, переданный Dst в момент T2, прибывает на Src.

6.5. Обсуждение

Этот показатель определяет «полезную в общем случае» связность – Src может передать Dst пакет, вызывающий отклик. Поскольку многие приложения используют разные типы пакетов для прямого и обратного трафика, возможно (и вероятно), что желаемым откликом на пакет Type-P1 будет Type-P2. Поэтому данная метрика допускает разные типы пакетов в каждом направлении.

6.6. Методики

Далее кратко описан класс методик оценки Type-P1-P2-Interval-Temporal-Connectivity. Это именно класс, а не отдельная методика, поскольку детали зависят от типов P1 и P2.

6.6.1. Входные данные

• Типы P1 и P2, адреса A1 и A2, интервал [T, T+dT].

• N – число пакетов, передаваемых для зондирования связности.

• W – «время ожидания», ограничивающие продолжительность осмысленного ожидания отклика на пакет.

Требования. W <= 255, dT > W.

6.6.2. Рекомендуемые значения

dT = 60 секунд.

W = 10 секунд.

N = 20 пакетов.

6.6.3. Алгоритм

• Задаются N значение времени отправки случайными числами с однородным распределением из интервала [T, T+dT-W].

• В каждый момент отправки от A1 передаётся пакет с корректным форматом P1 по адресу A2.

• Отслеживается входящий трафик на A1 на предмет получения отклика. Детали отслеживания зависят от типов P1 и P2, как описано ниже. При получении пакета устанавливается результат измерения true и процесс можно завершать.

• Если отклика не получено к моменту T+dT, устанавливается результат измерения false.

6.6.4. Обсуждение

Алгоритм неточен, поскольку он не проверяет (и не способен) временную связность в каждый момент интервала [T, T+dT]. Значение N задаёт компромисс между точностью и загрузкой сети. Состояние исследований Internet пока не даёт точных рекомендация по выбору N. Приведённые выше значения являются лишь ориентировочными.

6.6.5. Методика для TCP

В методе TCP-port-N1-port-N2 передаются пакеты TCP SYN из порта N1 в порт N2 по адресу A2. Входящий трафик A1 интерпретируется, как описано ниже.

• Пакет SYN-ack от A2 к A1 с подходящими полями подтверждения и номерами портов указывает временную связность. Измерение сразу же завершается с результатом true.

  {Комментарий. Если в качестве побочного эффекта этого метода полностью организовано соединение TCP между A1 и A2, т. е. стек TCP в A1 подтверждает пакет A2 SYN-ack, завершая трехэтапное согласование, соединение между A1 и A2 лучше всего разорвать с использованием обычного FIN, а не пакета RST, поскольку для RST не обеспечивается гарантия доставки. Если трехэтапное согласование не завершено, как в случае, когда средство измерения в A1 синтезирует свой начальный пакет SYN вместо его создания через стек TCP в A1, стек TCP хоста A1 будет автоматически разрывать соединение надёжным способом, когда A2 будет продолжать передачу SYN-ack в попытке организовать соединение. В заключение отметим, что использование стека TCP в A1 для проведения измерений усложняет метод, поскольку стек может повторно передать исходный пакет SYN, меняя число переданных зондов.}

• Пакет RST от A2 к A1 с корректными номерами портов указывает временную связность между адресами (и отсутствие связности для TCP-port-N1-port-N2, которую вероятно следует проверять с другой метрикой).

• Пакет ICMP port-unreachable от A2 к A1 указывает временную связность между хостами (и отсутствие связности для TCP-port-N1-port-N2).

  {Комментарий. Реализации TCP обычно не требуется передавать сообщения ICMP port-unreachable, поскольку имеется иной механизм – отправка RST). Однако в RFC 1122 сказано, что стек TCP при получении ICMP port-unreachable должен трактовать это как эквивалентный механизм транспортного уровня (RST для TCP).}

• Сообщение ICMP host-unreachable или network-unreachable хосту A1 (не обязательно от A2) с вложенным заголовком IP, соответствующим переданному от A1 к A2, указывает отсутствие временной связности. Если к моменту T+dT подтверждения временной связности не будет получено, приём ICMP можно считать дополнительной информацией для установки результата измерения false.

{Комментарий. Нужны аналогичные методики для ICMP Echo, UDP и т. п.}

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

Спасибо Guy Almes, Martin Horneffer, Jeff Sedayao, Sean Shapira за их комментарии.

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

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

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

[RFC1812] Baker, F., “Requirements for IP Version 4 Routers”, RFC 1812, June 1995.

[RFC1122] Braden, R., Editor, “Requirements for Internet Hosts – Communication Layers”, STD, 3, RFC 1122, October 1989.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, “Framework for IP Performance Metrics”, RFC 2330, May 1998.

[RFC791] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.

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

Jamshid Mahdavi

Pittsburgh Supercomputing Center

4400 5th Avenue

Pittsburgh, PA 15213

USA

EMail: mahdavi@psc.edu

 

Vern Paxson

MS 50A-3111

Lawrence Berkeley National Laboratory

University of California

Berkeley, CA 94720

USA

Phone: +1 510/486-7504

EMail: vern@ee.lbl.gov

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

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

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

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

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

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

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

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

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

nmalykh@protokols.ru