DSR

Dynamic Source Routing (DSR) (Динамическая маршрутизация от источника) — протокол маршрутизации для MANET с топологией mesh. Cхож c AODV в том, что также формирует маршрут по-требованию, посредством передачи broadcast-запроса. Однако, он использует явную маршрутизацию, не полагаясь на таблицы маршрутизации на каждом промежуточном устройстве. Кроме того, в DSR было внесено множество последовательных конкретизаций, включая DSR-Flow (гибрид явной маршрутизации и маршрутизации по таблицам).

Явное задание маршрута требует накопления адресов каждого устройства между источником и приемником во время его поиска. Информация о накопленном пути пополняется узлами, обрабатывающими broadcast-запросы источника. Изученные таким образом пути и используются для маршрутизации пакетов. В результате, маршрутизируемые пакеты содержат адрес каждого устройства, через которое они прошли. Из-за увеличения заголовков пакетов, это может привести к избыточности служебного потока данных для длинных путей или больших адресов, как в IPv6. Для таких ситуаций в DSR-Flow определена опция «flow id», которая позволяет пакетам быть отправленными в соответствии с таблицами маршрутизации (она может активироваться для далеких маршрутов).

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

Чтобы послать ответ на запрос, у узла адресата должен быть маршрут к исходному узлу. Если бы маршрут находился в кэше, использовалась бы кешированная запись. Иначе маршрут к исходному узлу будет определен на основе сохраненного в цепочке пути пакета-запроса (для этого необходимо, чтобы все каналы в сети были симметричны). В случае удачной передачи ответа инициализируется поддержки, посредством которой пакеты оповещающие об ошибке передачи, будут учитываться узлом. В результате испорченный канал связи будет удален из кэша маршрутов узла, как и все маршруты, содержащие этот канал. Затем будет повторно инициирована фаза поиска нового жизнеспособного пути.

Динамический протокол маршрутизации от источника (DSR) по требованию, создавался для того, чтобы уменьшить трафик, потребляемый управляющими пакетами в беспроводных сетях, устраняя сообщения обновления таблицы, требуемые в подходе с формированием маршрутов при помощи таблиц. Главное различие между этим и другим реактивными протоколами маршрутизации — то, что в нем отсутствуют «маяки» и следовательно не требует периодической передачи пакета приветствия, которые используются узлом, чтобы сообщить соседям о его присутствии. Основной подход этого протокола (как и других реактивных протоколов маршрутизации) состоит в том, что во время фазы конструкции маршрута узел устанавливает маршрут, рассылая широковещательные пакеты RouteRequest по сети. Узел адресата, при получении пакета RouteRequest, отвечает, отсылая пакет RouteReply назад к источнику, который несет маршрут, пройденный полученным пакетом RouteRequest.

Рассмотрим исходный узел, у которого нет маршрута к адресату. Когда у него есть пакеты данных, которые будут посланы адресату, он инициализирует пакет RouteRequest, который распространяется по сети. Каждый узел, после получения пакета RouteRequest, повторно передает пакет своим соседям, (если ещё не передал, так как копия пакета может прийти к нему от другого узла), при условии, что узел не является адресатом и что время жизни пакета (TTL) не было превышено. У каждого RouteRequest есть порядковый номер, сгенерированный исходным узлом и узлами, через которые он прошел. Узел, после получения пакета RouteRequest, проверяет порядковый номер на пакете прежде, чем отправить его. Пакет отправлен, только если это не дублирующийся RouteRequest. Порядковый номер на пакете используется, чтобы предотвратить формирования цикла и избежать множественных передач одного и того же RouteRequest промежуточным узлом, который получает его через несколько каналов. Таким образом, все узлы кроме адресата отправляют пакет RouteRequest во время фазы формирования маршрута. Узел адресата, после получения первого пакета RouteRequest, отвечает источнику через обратный путь, который пересек пакет RouteRequest. Узлы могут также узнать о соседних маршрутах, пересеченных пакетами данных если задан режим промискуитета (режим работы, в котором узел может получить пакеты, которые не переданы, и не адресованы ему). Этот кэш маршрута также используется во время фазы формирования маршрута. Если у промежуточного узла, получающего RouteRequest, есть маршрут к узлу адресата в его кэше маршрута, то он отвечает на исходный узел, посылая RouteReply со всей информацией маршрута от исходного узла до узла адресата.

Преимущества и недостатки

Этот протокол использует реактивный подход, который избавляет от необходимости периодически засорять сеть сообщениями обновления таблицы, которые требуются в подходе с формированием маршрутов при помощи таблиц маршрутизации. В реактивных (по требованию) протоколах маршрут устанавливается только, когда он требуется и следовательно потребность в поиске путей ко всем другим узлам в сети как делается в подходом с формированием маршрутов при помощи таблиц отсутствует. Промежуточные узлы также эффективно используют информацию кэша маршрута, чтобы уменьшить издержки. Недостаток этого протокола — то, что механизм обслуживания маршрута в местном масштабе не восстанавливает разорванные соединения. Устаревшая информация из кэша маршрута может также привести к несогласованностям во время фазы реконструкции маршрута. Задержка установки подключения выше, чем в протоколах, использующих таблицы. Даже при том, что протокол хорошо работает в статических средах и средах с низкой подвижностью узлов, производительность быстро ухудшается с увеличивающейся подвижностью. Кроме того, значительные издержки маршрутизации появляются из за маршрутизации от источника, используемой в DSR. Эти издержки прямо пропорциональны длине пути.

Ссылки

RFC 4728

Для улучшения этой статьи желательно?: Викифицировать статью. Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.