Приложения протокола розыска соседей

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

Рис. 6.5. Сеть выбирает узел anycast в зависимости от точки подключения хоста

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

Допустим, что источник по-прежнему не подозревает об особенностях адреса X и работает с ним, как с обычным индивидуальным адресом. По условию задачи, адрес X — "на канале". Поэтому источник первым делом проведет розыск соседа X, направив вызов NS группе искомого узла Г(X), как мы обсудили в §5.1. Если наши узлы anycast заранее вступят в эту группу, то все они, в идеале, получат NS и ответят на него объявлениями NA. В результате источник получит несколько объявлений NA об одном и том же сетевом адресе цели X, но все они будут с разными канальными адресами, как показано на рис. 6.6.

Рис. 6.6. Anycast в пределах канала

Потенциально эти объявления могут состязаться за запись в кэше NC источника, меняя ее непредсказуемым образом. Поэтому нам надо позаботиться, чтобы узлы anycast не воевали между собой. Гарантией мира будет сброшенный флаг O ( O = 0) в их объявлениях NA насчет адреса цели X. Тогда в кэше NC закрепится канальный адрес из объявления, пришедшего самым первым. Последующие объявления станут переводить запись в состояние ПРОСРОЧЕННАЯ, но она будет возвращаться в состояние ДОСТУПНАЯ, не меняя канального адреса, благодаря процедуре NUD. Таким образом, вещание наугад будет воспроизводимым и в этом случае.

Если на канале будет много источников вещания наугад и все они обратятся по адресу X, то их обращения распределятся между узлами anycast случайным образом. Так вещание наугад можно использовать для распределения нагрузки на узлы.

Пока что в нашей схеме узлы anycast отвечают на каждый вызов NS "хором", а это приведет к пикам нагрузки на канал. Чтобы сгладить эти пики, пусть каждый узел anycast задерживает объявление NA на случайное время, от 0 до заданного потолка^{1 Параметр MAX_ANYCAST_DELAY_TIME, 1 с [§10 RFC 4861].} [§7.2.4 RFC 4861].

А что произойдет, если выбранный узел anycast через какое-то время станет недоступен, скажем, его просто выключат? Тогда источник вычистит запись об адресе X из NC благодаря NUD, и цикл розыска повторится с начала. В результате источник переключится на другой, доступный узел anycast. Так оказывается, что вещание наугад в рамках одного канала открывает путь не только к распределению нагрузки, но и к резервированию.

Итак, мы рассмотрели два независимых сценария с вещанием наугад. Можно ли их объединить, чтобы охватить все возможные случаи? Конечно! Если мы поместим между источником и каналом с узлами anycast маршрутизатор, как показано на рис. 6.7, то выбирать узел anycast придется маршрутизатору, но он с этой задачей вполне справится. Ведь выбор узла anycast по адресу ничем не отличается от обычного розыска соседа. Однако у гибридного сценария есть важное отличие от сценария "все на одном канале": если несколько источников станут обращаться по адресу anycast через один и тот же маршрутизатор, то все обращения пойдут на один и тот же узел anycast. В этом случае распределения нагрузки не произойдет.

Рис. 6.7. Anycast на канале через маршрутизатор

Остался последний вопрос касательно вещания наугад: какова структура "волшебного" адреса anycast? Возникнет ли у нас новый тип адреса IPv6? Нет, не возникнет. "Построенная" нами схема вещания наугад в IPv6 явно требует, чтобы адрес anycast ничем не отличался от индивидуального адреса. Только при этом условии вещание наугад можно вести на основе уже доступных механизмов, маршрутизации и ND. Узнать, что данный адрес — anycast, можно только из настроек узла, которому он назначен, и только такой узел работает с адресом anycast чуть иначе.

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