Network Working Group                                  Jeffrey Mogul
Request for Comments: 919                Computer Science Department
                                                 Stanford University
                                                        October 1984

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

BROADCASTING INTERNET DATAGRAMS

PDF

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

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

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

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

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

1. Введение

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

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

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

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

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

Отметим, что некоторые организации делят свою сеть IP на подсети, в соответствии с предложенным стандартом [8]. Данный документ не рассматривает вопросы широковещательной рассылки в среде с подсетями (эта тема рассматривается в работе [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^2.

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

7.1. Широковещательные адреса и серверы ARP

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

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

1. David Reeves Boggs. Internet Broadcasting. Ph.D. Th., Stanford University, January 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, April 1977.
4. Yogan K. Dalal and Robert M. Metcalfe. “Reverse Path Forwarding of Broadcast Packets”. Comm. ACM 21, 12, pp1040-1048, December 1978.
5. The Ethernet, A Local Area Network: Data Link Layer and Physical Layer Specifications. Version 1.0, Digital Equipment Corporation, Intel, Xerox, September 1980.
6. Robert Gurwitz and Robert Hinden. IP – Local Area Network Addressing Issues. IEN-212, Bolt Beranek and Newman, September 1982.
7. R.M. Metcalfe and D.R. Boggs. “Ethernet: Distributed Packet Switching for Local Computer Networks”⁴. Comm. ACM 19, 7, pp395-404, July 1976. Also CSL-75-7, Xerox Palo Alto Research Center, reprinted in CSL-80-2.
8. Jeffrey Mogul. Internet Subnets. RFC-917, Stanford University, October 1984.
9. Jeffrey Mogul. Broadcasting Internet Packets in the Presence of Subnets. RFC 922, Stanford University, October 1984.
10. David A. Moon. Chaosnet. A.I. Memo 628, Massachusetts Institute of Technology Artificial Intelligence Laboratory, June 1981.
11. William W. Plummer. Internet Broadcast Protocols. IEN-10, Bolt Beranek and Newman, March 1977.
12. David Plummer. An Ethernet Address Resolution Protocol⁶. RFC 826, Symbolics, September 1982.
13. Jon Postel. Internet Protocol. RFC 791, ISI, September 1981.
14. David W. Wall. Mechanisms for Broadcast and Selective Broadcast. Ph.D. Th., Stanford University, June 1980.
15. David W. Wall and Susan S. Owicki. Center-based Broadcasting. Computer Systems Lab Technical Report TR189, Stanford University, June 1980.

---

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

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

nmalykh@protokols.ru