RFC: 922
Оригинал: Broadcasting Internet datagrams in the presence of subnets
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 922, Страница 5 из 9

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

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

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

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

  • Формат дейтаграмм IP не должен изменяться.

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

  • Минимальные изменения для шлюзов (как для кода, так и для пространства данных).

  • Высокая вероятность доставки дейтаграмм.

Лучшим вариантом представляется метод RPF (Reverse Path Forwarding – рассылка по обратному пути) [4]. Хотя алгоритм RPF не совсем оптимален с точки зрения стоимости и надежности доставки, он достаточно хорош и очень прост в реализации, а также не требует дополнительного пространства данных на шлюзах.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.