RFC 919 Широковещательная рассылка дейтаграмм IP

Request for Comments: 
919
Название: 
Широковещательная рассылка дейтаграмм IP
Статус документа

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

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

1. Введение

Использование широковещательной адресации (особенно в скоростных ЛВС) обеспечивает хорошую базу для множества приложений. Поскольку широковещательная адресация не рассматривается в базовой спецификации IP RFC 791 [13], не существует согласованного способа использования широковещательных адресов и разработчики не могут пользоваться такой адресацией (этот вопрос поднимался и ранее — например, в работе [6], но стандарт не был предложен).

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

Мы предполагаем, что канальный уровень локальной сети поддерживает эффективный механизм широковещания (например, Ethernet [7, 5], ChaosNet [10], token ring [2] и т. п.).

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

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

Отметим, что некоторые организации делят свою сеть IP на подсети, в соответствии с предложенным стандартом RFC 917 [8]. Данный документ не рассматривает вопросы широковещательной рассылки в среде с подсетями (эта тема рассматривается в работе RFC 922 [9]).

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

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

    Локальная сеть (Local Hardware Network) — Физическая сеть, к которой подключен хост.
    Удаленная физическая сеть (Remote Hardware Network) — Физическая сеть, отделенная от хоста по крайней мере одним маршрутизатором.
    Набор удаленных сетей (Collection of Hardware Networks) — Набор физических сетей, соединенных через маршрутизаторы.

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

    Internet — Набор IP-сетей DARPA Internet.
    Сеть IP (IP Network) — Одна или несколько физических сетей, имеющих общий номер IP.

3. Зачем нужно широковещание?

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

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

Использование списков подключенных к сети хостов порождает множество административных проблем и не обеспечивает достаточной гибкости. С другой стороны, передача запросов всем соседям будет занимать много времени по причине большого числа соседей (например, в сети ARPANET существует около 65 тысяч хостов). Большинство реализаций IP поддерживает списки подключенных к сети хостов (например, адреса Prime-шлюзов). К счастью, использование широковещательной рассылки обеспечивает хосту простой и быстрый способ связи со всеми соседями.

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

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

Более подробное рассмотрение широковещательных приложений приводится в работах [1, 3].

4. Классы широковещания

Существует несколько классов широковещания IP:

    Широковещательная рассылка дейтаграмм с конкретным адресом получателя через локальную сеть IP: дейтаграммы направлены конкретному адресату, но передающий хост использует широковещание на канальном уровне (возможно, для того, чтобы избежать маршрутизации). Поскольку такое широковещание не относится к IP, уровень IP не участвует в широковещательной рассылке (за исключением того, что он обеспечивает отбрасывание дейтаграмм без уведомления).
    Широковещательная рассылка всем хостам локальной сети IP: в качестве номера хоста используется специальное значение. Принимающий уровень IP должен распознавать такой адрес, как свой собственный. Однако, но вышележащих уровнях может быть полезно различие между широковещательными и обычными дейтаграммами (особенно на маршрутизаторах). Этот вариант широковещания наиболее полезен — он позволяет хостам детектировать шлюзы (маршрутизаторы) без использования протоколов преобразования адресов, а также обеспечивает возможность работы с серверами имен, серверами времени и др. службами без использования явного адреса.
    Широковещательная рассылка всем хостам удаленной сети IP: в некоторых случаях такая рассылка может оказаться полезной (например, для поиска последней версии базы данных с именами хостов, удаленной загрузки или мониторинга сетевой службы точного времени). Этот случай совпадает с широковещательной рассылкой в локальной сети — дейтаграмма передается обычным путем, пока она не попадет на маршрутизатор, подключенный к сети-адресату, который и организует широковещательную рассылку в своей локальной сети. Этот класс называется направленным широковещанием (directed broadcasting) или letter bomb [1].
    Широковещательная рассылка в масштабе Internet: такая рассылка вряд ли полезна и, во всяком случае, нежелательна.

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

5. Методы широковещания

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

Вопросы оптимизации широковещательной рассылки подробно рассмотрены в работах [1, 3, 4, 14, 15]. Поскольку мы предполагаем, что эта проблема уже решена на канальном уровне, хост IP желающий передать широковещательную дейтаграмму в локальную или удаленную сеть (directed broadcast) должен лишь указать подходящий адрес получателя и передать дейтаграмму обычным путем. Изощренные алгоритмы обработки широковещания требуются только шлюзам.

6. Шлюзы и рассылка широковещательных дейтаграмм

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

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

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

7. Широковещательная адресация IP — предложенные стандарты

Для совместимости реализаций IP они должны поддерживать специальный номер для обозначения всех хостов сети (all hosts).

Поскольку сетевой уровень локальной сети всегда отображает адреса IP на адреса канального уровня, выбор широковещательного номера IP (broadcast host number) является в какой-то степени произвольным. Для простоты этот номер не должен совпадать ни с одним из реальных номеров хостов. Номер, содержащий только «1», удовлетворяет этому требованию; использование таких номеров для широковещания было впервые предложено в работе [6]. Такие номера достаточно редко используются для реальных хостов, поэтому использование этого номера для широковещательной рассылки скорей всего не потребует каких-либо изменений в конфигурации сети.

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

    Рассылать дейтаграммы своим непосредственным соседям по локальной сети, используя адрес 255.255.255.255
    Рассылать широковещательные дейтаграммы по всей сети 36, используя адрес 36.255.255.255

Если «все единицы» в поле адреса IP используются для широковещания, значение «все нули» можно использовать для неуказанного адреса (unspecified). Возможно это является причиной появления таких значений в поле отправителя дейтаграмм ICMP Information Request. Однако в соответствии с соглашением о нотации такие адреса (все нули) используются для обозначения сетей. Например, 36.0.0.0 означает "сеть номер 36", а 36.255.255.255 — широковещательный адрес «все хосты сети 36".
7.1. Широковещательные адреса и серверы ARP

Протокол преобразования адресов ARP, описанный в RFC 826 [12], может при некорректной реализации порождать проблемы, связанные с использованием широковещания в сетях, где не все хосты понимают какой адрес является широковещательным. Возникает искушение изменить сервер ARP так, чтобы он мог обеспечивать отображение широковещательных адресов IP в широковещательные аппаратные адреса. Этому искушению не следует поддаваться. Серверу ARP никогда не следует давать отклики на запросы, в которых получатель задан широковещательным адресом. Такие запросы могут исходить только от хостов, которые не распознают этот адрес в качестве широковещательного (это легко приводит к возникновению петель в пересылке). Если имеется N таких хостов в физической сети, тогда дейтаграмма, переданная со значением TTL = T, может привести к генерации T^N повторных широковещательных дейтаграмм.

8. Литература
[1]	David Reeves Boggs. Internet Broadcasting. Ph.D. Th., Stanford University, Январь 1982.
[2]	D.D. Clark, K.T. Pogran, and D.P. Reed. «An Introduction to Local Area Networks». Proc. IEEE 66, 11, pp1497-1516, 1978.
[3]	Yogan Kantilal Dalal. Broadcast Protocols in Packet Switched Computer Networks. Ph.D. Th., Stanford University, Апрель 1977.
[4]	Yogan K. Dalal and Robert M. Metcalfe. «Reverse Path Forwarding of Broadcast Packets». Comm. ACM 21, 12, pp1040-1048, Декабрь 1978.
[5]	The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications. Version 1.0, Digital Equipment
[6]	Robert Gurwitz and Robert Hinden. IP - Local Area Network Addressing Issues. IEN-212, Bolt Beranek and Newman, Сентябрь 1982.
[7]	R.M. Metcalfe and D.R. Boggs. «Ethernet: Distributed Packet Switching for Local Computer Networks». Comm. ACM 19, 7, pp395-404, Июль 1976. Also CSL-75-7, Xerox Palo Alto Research Center, reprinted in CSL-80-2.
[8]	Jeffrey Mogul, «Подсети Internet», RFC 917, Октябрь 1984.
[9]	Jeffrey Mogul, «Широковещательная рассылка дейтаграмм IP при наличии подсетей», RFC 922, Октябрь 1984.
[10]	David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, Июнь 1981.
[11]	William W. Plummer. Internet Broadcast Protocols. IEN-10, Bolt Beranek and Newman, Март 1977.
[12]	David C. Plummer, «Протокол преобразования адресов Ethernet (ARP)», RFC 826, Ноябрь 1982.
[13]	J. Postel, «Протокол IP (Internet Protocol)», RFC 791, Сентябрь 1981.
[14]	David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, Июнь 1980.
[15]	David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, Июнь 1980.
Благодарности

Этот документ был создан в результате дискуссий с целой группой специалистов. Особенно отмечу вклад J. Noel Chiappa и Christopher A. Kent.
Русский