свойство

Алгоритм дырявого ведра формирует строгий выходной поток с постоянной ско­ростью, не зависящей от неравномерности входного потока. Для многих прило­жений было бы лучше при поступлении больших пакетов данных немного увели­чивать выходную скорость. Таким образом можно было бы попытаться создать более гибкий алгоритм, желательно, не теряющий данные. Одним из таких алго­
ритмов является алгоритм маркерного ведра. В этом алгоритме ведро содержит маркеры, создаваемые через равные интервалы времени ДТ секунд. На рис. 5.30, а изображено ведро с тремя маркерами и пятью пакетами, стоящими в очереди. Чтобы передать один пакет, требуется удалить один маркер. На рис. 5.30, б мы ви­дим, что три из пяти пакетов прошли в сеть, а оставшиеся два пакета остались ждать двух новых маркеров.

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

Еще одно различие двух алгоритмов заключается в том, что при переполне­нии маркерного ведра алгоритм игнорирует маркеры, но никогда не отвергает пакеты. Алгоритм дырявого ведра, напротив, при переполнении выбрасывает са­ми пакеты.

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

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

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

Суть алгоритма маркерного ведра состоит в том, что он допускает передачу Данных пачками, но ограничивает длительность пачки. Для примера рассмотрим рис. 5.29, в, на котором изображено маркерное ведро емкостью 250 Кбайт. Мар­керы появляются с частотой, соответствующей выходной скорости 2 Мбайт/с. Предположим, что маркерное ведро заполнено, когда прибывает пакет данных , размером 1 Мбайт. Ведро может быть освобождено с максимальной скоростью 25 Мбайт/с примерно за 11 мс. Затем оно должно уменьшить скорость передачи ' До 2 Мбайт/с, пока не будет передан весь входной пакет данных.

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

Один из способов получения более гладкого трафика состоит в помещении дырявого ведра после маркерного ведра. Скорость дырявого ведра должна быть выше минимальной скорости маркерного ведра р, но ниже максимальной скоро­сти сети. На рис. 5.29, е показан выходной поток маркерного ведра емкостью 500 Кбайт, за которым установлено дырявое ведро со скоростью протекания, равной 10 Мбайт/с.

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

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

Процесс принятия решения об обработке или игнорировании потока сложнее, нежели простое сравнение запрашиваемых потоком параметров (пропускной спо­собности, буферной памяти, времени центрального процессора) с имеющимися. Во-первых, хотя многие приложения и знают свои требования к пропускной способности, они понятия не имеют, какой объем буферной памяти и сколько тактов работы процессора им требуется. Следовательно, нужен, по крайней мере, иной способ описания потоков. Далее, приложения весьма различаются по толе­рантности в отношении пропущенного предельного срока обработки. Наконец, некоторые приложения могут поторговаться за параметры пакетов, а некоторые не могут. Скажем, проигрыватель видео, предоставляющий обычно 30 кадров/с, хожет согласиться работать на 25 кадрах/с, если для 30 не хватает пропускной способности. Аналогично, можно настраивать количество пикселов на кадр, по­лосу пропускания для аудиоданных и другие свойства потоков различных при­ложений.

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

В качестве содержимого спецификации потока рассмотрим пример, базирую­щийся на RFC 2210 и RFC 2211 (табл. 5.4). В спецификации содержится пять параметров, первый из которых, Скорость маркерного ведра, хранит число бай­тов, поступающих в «ведро» за секунду. Это максимум, который отправитель мо­жет поддерживать в течение длительного времени, усредненный по большому временному отрезку.Второй параметр — размер маркерного ведра в байтах. Если, к примеру, Ско­рость маркерного ведра составляет 1 Мбит/с, а размер ведра равен 500 Кбайт, то его можно будет наполнять данными в течение 4 с. Все, что будет посылаться по­сле этого, будет теряться.

Третий параметр, Пиковая скорость передачи данных, — это максимальная до­пустимая скорость даже для коротких промежутков времени. Отправитель ни в коем случае не должен превышать это значение.

Наконец, последние два параметра определяют минимальный и максималь­ный размеры пакетов, включая заголовки транспортного и сетевого уровней (на­пример, TCP и IP). Минимальный размер важен, поскольку обработка каждого пакета занимает какое-то, пусть даже очень малое, время. Маршрутизатор, мо­жет быть, готов принимать 10 000 пакетов в секунду по 1 Кбайт каждый, но не готов обрабатывать 100 ООО пакетов по 50 байт в секунду несмотря на то, что во втором случае скорость передачи данных меньше, чем в первом. Максимальный размер пакета не менее важен, но уже по другой причине. Дело в том, что сущест­вуют определенные внутрисетевые ограничения, которые ни в коем случае не должны быть превышены. Например, если путь потока лежит через Ethernet, то максимальный размер пакета будет ограничен 1500 байтами независимо от того, какого размера пакеты могут поддерживать другие части сети.

Интересно, каким образом маршрутизатор преобразует спецификацию пото­ка в набор определенных резервируемых ресурсов? Это отображение является специфическим и не стандартизованным действием. Допустим, маршрутизатор может обрабатывать 100 000 пакетов/с. Если ему предлагается пропустить через себя поток со скоростью 1 Мбайт/с с максимальным размером пакета, состав­ляющим 512 байт, он может легко посчитать, что такой поток дает 2048 паке­тов/с, значит, под него необходимо отвести 2 % времени работы процессора, а лучше немного больше, чтобы избежать больших задержек обслуживания. Ес­ли политика маршрутизатора не позволяет ему резервировать более 50 % про­цессорного времени (что подразумевает половинную задержку) и если 49 % уже зарезервировано, то поток будет отвергнут. Подобные вычисления необходимо производить для всех резервируемых ресурсов.

Чем строже спецификация потока, тем лучше для маршрутизаторов. Если же в спецификации говорится, что Скорость маркерного ведра составляет 5 Мбайт/с, однако пакеты могут быть размером от 50 до 1500 байт, значит, скорость переда­чи пакетов может колебаться от 3500 до 105 000 пакетов/с. Маршрутизатор, ужаснувшись при виде последнего числа, может отвергнуть такой поток. При ми­нимальном размере пакета, равном 1000 байт, 5-мегабайтный поток тем же са­мым маршрутизатором мог бы быть принят.

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

Далее, какая организация будет заведовать Управлением? Довольно трудно представить себе какую-либо законную структуру с большим кредитом доверия мирового масштаба. В некоторых странах предпочтительно, чтобы это было ка- кое-нибудь правительственное учреждение, а где-то — наоборот, чтобы это было чем угодно, но не правительством.

По этим причинам был разработан альтернативный способ сертификации открытых ключей. Он известен под общим названием PKI (Public Key Infra­structure — инфраструктура систем с открытыми ключами). В этом разделе мы
рассмотрим только общие принципы действия PKI, поскольку было внесено мно­жество предложений по ее модификации и некоторые детали могут со временем измениться.

PKI состоит из множества компонентов, среди которых Управления сертифи­кации, сами сертификаты, а также каталоги. Инфраструктура систем с открытыми ключами предоставляет возможность структурной организации этих компонен­тов и определяет стандарты, касающиеся различных документов и протоколов. Одним из простейших видов PKI является иерархия Управлений, представлен­ная на рис. 8.22. На рисунке представлены три уровня, однако реально их может быть как больше, так и меньше. Управление сертификации верхнего уровня (root) мы будем называть Центральным управлением (ЦУ). Центральное управление сертифицирует управления второго уровня — назовем их Региональными отде­лами (РО), — так как они могут обслуживать некоторый географический регион, например, страну или континент. Этот термин не стандартизован. Названия для уровней иерархии вообще не оговариваются стандартом. Региональные отделы, в свою очередь, занимаются легализацией реальных Управлений сертификации (УС), эмитирующих сертификаты стандарта Х.509 для физических и юриди­ческих лиц. При легализации Центральным управлением нового Регионального отдела последнему выдается сертификат, подтверждающий его признание. Он содержит открытый ключ нового РО и подпись ЦУ. Аналогичным образом РО взаимодействуют с Управлениями сертификации: выдают и подписывают серти­фикаты, содержащие открытые ключи УС и признающие легальность деятель­ности.

РО 2 принят. Открытый ключ: 47383АЕ349...

Подпись ЦУ

РО 2 и содержащий открытый ключ УС 5. Теперь, вооружившись открытым ключом УС 5, Алиса может удостовериться в том, что сертификат Боба действи­тельно подписан УС 5, а значит, является легальным.

Если только РО 2 не является двенадцатилетним сыном Боба. Если Алисе вдруг придет в голову такая мысль, она может запросить подтверждение леги­тимности РО 2. Ответом будет служить сертификат, подписанный Центральным управлением и содержащий открытый ключ РО 2. Вот теперь Алиса может не сомневаться, что она получила открытый ключ Боба, а не кого-то другого.

А если Алиса хочет узнать открытый ключ ЦУ? Как это сделать? Загадка. Предполагается, что открытый ключ ЦУ знают все. Например, он может быть «зашит» внутрь ее браузера.

Но наш Боб — добряк, он не хочет доставлять Алисе лишние хлопоты. Он по­нимает, что она захочет проверить легитимность УС 5 и РО 2, поэтому он сам собирает соответствующие сертификаты и отправляет их ей вместе со своим. Те­перь, зная открытый ключ ЦУ, Алиса может проверить по цепочке все интере­сующие ее организации. Ей не придется никого беспокоить для подтверждения. Поскольку все сертификаты подписаны, она может запросто уличить любые по­пытки подлога. Цепочка сертификатов, восходящая к ЦУ, иногда называется до­верительной цепочкой или путем сертификата. Описанный метод широко при­меняется на практике.

Конечно, остается проблема определения владельца ЦУ. Следует иметь не од­но Центральное управление, а несколько, причем связать с каждым из них свою иерархию региональных отделов и управлений сертификации. На самом деле, в современные браузеры действительно «зашиваются» открытые ключи более 100 центральных управлений, иногда называемые доверительными якорями. Как видите, можно избежать проблемы одного всемирного учреждения, занимающе­гося сертификацией.

Однако встает вопрос, какие доверительные якоря производители браузеров могут считать надежными, а какие — нет. Все, на самом деле, сводится к тому, насколько конечный пользователь доверяет разработчику браузера, насколько он уверен в том, что решения генерируются грамотно и доверительные якоря не принимаются от всех желающих за умеренную плату. Большинство браузеров обеспечивают возможность проверки ключей ЦУ (обычно это делается с помо­щью сертификатов, подписанных им) и удаления подозрительных ключей.

Каталоги

Инфраструктура систем с открытыми ключами должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведущих к какому-нибудь доверительному якорю). Можно заставить всех пользователей хранить свои сер­тификаты у себя. Это безопасно (так как невозможно подделать подписанные сертификаты незаметно), но не слишком удобно. В качестве каталога для серти­фикатов было предложено использовать DNS. Прежде чем соединиться с Бобом, Алисе, видимо, все равно придется узнать с помощью службы имен доменов (DNS) его IP-адрес. Так почему бы не заставить DNS возвращать вместе с 1Р-ад- ресом всю цепочку сертификатов?

Кому-то это кажется выходом из положения, однако некоторые считают, что лучше иметь специализированные серверы с каталогами для хранения серти­фикатов Х.509. Такие каталоги могли бы с помощью имен Х.500 обеспечивать возможность поиска. Например, теоретически можно представить себе услугу сер­вера каталогов, позволяющую получать ответы на запросы типа «Дайте мне пол­ный список всех людей по имени Алиса, работающих в отделе продаж в любом месте США или Канады». Хранить такую информацию можно, например, при помощи LDAP.

Аннулирование

Реальный мир полон разного рода сертификатов, среди которых, например, пас­порта, водительские удостоверения. Иногда эти сертификаты необходимо анну­лировать (например, водительское удостоверение надо аннулировать за езду в нетрезвом состоянии). Та же проблема возникает и в мире цифровых технологий: лицо, предоставившее сертификат, может отозвать его за нарушение противопо­ложной стороной каких-либо условий. Это необходимо делать и тогда, когда за­крытый ключ, в сущности, перестал быть защищенным или, что еще хуже, ключ УС потерял кредит доверия. Таким образом, инфраструктура систем с открыты­ми ключами должна как-то обеспечивать процедуру аннулирования.

Первым шагом в этом направлении является принуждение всех УС к перио­дическому выпуску списка аннулированных сертификатов (CRL — Certificate Revocation List). В нем перечисляются порядковые номера всех аннулированных сертификатов. Поскольку в сертификатах содержится дата окончания срока год­ности, в CRL следует включать номера только тех из них, срок годности которых еще не истек. По истечении срока годности сертификаты перестают быть дейст­вительными автоматически, поэтому нужно различать случаи аннулирования «по старости» и по другим причинам. В любом случае их использование необхо­димо запрещать.

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

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

Где хранить списки аннулированных сертификатов? Было бы здорово хра­нить их там же, где и сами сертификаты. Одна из стратегий подразумевает, что

УС периодически выпускает «черные» списки и заставляет вносить обновления в каталоги (удаляя отозванные сертификаты). Если для хранения сертификатов каталоги не используются, можно кэшировать их в разных удобных местах в се­ти. Поскольку «черный» список сам по себе является подписанным документом, любые попытки подлога тотчас будут замечены.

Если сертификаты имеют большие сроки годности, списки аннулированных сертификатов также будут довольно длинными. Например, количество отозван­ных кредитных карточек со сроком годности 5 лет будет гораздо больше списка отозванных трехмесячных карточек. Стандартным способом борьбы с длинными списками является довольно редкий выпуск самих списков и частый — обновле­ний к ним. Кроме всего прочего, это помогает снизить необходимую для распро­странения списков пропускную способность.

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

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

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

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

Маршрутизация с учетом состояния линий широко применяется в современ­ных сетях, поэтому следует сказать несколько слов о некоторых примерах прото­колов, использующих данный алгоритм. Одним из таких протоколов является протокол OSPF, все чаще применяемый в Интернете, о котором будет рассказа­но в разделе «Протокол внутреннего шлюза OSPF».

Другим важным протоколом с учетом состояния линий является IS-IS (Intermediate System to Intermediate System — связь между промежуточными сис­темами) — протокол, разработанный для сети DECnet и принятый впоследствии Международной организацией по стандартизации ISO для использования вме­сте с протоколом сетевого уровня CLNP, не требующим соединений. С тех пор он был модифицирован для поддержки также и других протоколов, в частности IP. Протокол IS-IS используется в некоторых магистралях сети Интернет (включая старую магистраль NSFNET) и в некоторых цифровых сотовых системах, напри­мер, в CDPD. В сети Novell NetWare применяется разновидность протокола IS­IS (NLSP) для маршрутизации IPX-пакетов.

В основе работы протокола IS-IS лежит распространение картины топологии маршрутизаторов, по которой рассчитываются кратчайшие пути. Каждый мар­шрутизатор сообщает в информации о состоянии линий доступные ему напря­мую адреса сетевого уровня. Эти адреса могут быть адресами IP, IPX, AppleTalk или другими. Протокол IS-IS может даже осуществлять одновременную поддерж­ку нескольких протоколов сетевого уровня.

Создаются пакеты состояния линий несложно. Самое трудное заключается в выборе момента времени для их создания. Их можно создавать периодически через равные интервалы времени. Другой вариант состоит в создании пакетов, когда происходит какое-нибудь значительное событие — например, линия или сосед выходит из строя или, наоборот, снова появляется в сети либо существен­но изменяет свои свойства.

После того как информация, необходимая для обмена, собрана, следующий шаг, выполняемый каждым маршрутизатором, заключается в создании пакета, содер­жащего все эти данные. Пакет начинается с идентификатора отправителя, за ко­торым следует порядковый номер и возраст (описываемый далее), а также спи­сок соседей. Для каждого соседа указывается соответствующая ему задержка. Пример подсети приведен на рис. 5.11, а, на котором показаны задержки для каж­дой линии. Соответствующие пакеты состояния линий для всех шести маршру­тизаторов показаны на рис. 5.11, б.

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

• Военная техника на поле боя при отсутствии инфраструктуры.
• Морская флотилия, находящаяся в плавании.
• Работники служб спасения в районах с разрушенной инфраструктурой.

• Собрание людей с портативными компьютерами при отсутствии в поме­щении сети 802.11.
  

Во всех подобных случаях каждый узел состоит из маршрутизатора и хоста одновременно, обычно они даже совмещены в пределах одного компьютера. Се­ти, состоящие из узлов, волею судеб оказавшихся недалеко друг от друга, назы­ваются специализированными сетями, или мобильными специализированными сетями (MANET, Mobile Ad hoc networks). Давайте их вкратце рассмотрим. Бо­лее подробную информацию можно найти в книге (Perkins, 2001).

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

Известно множество алгоритмов выбора маршрута для специализированных сетей. Один из наиболее интересных — это алгоритм AODV (Ad hoc On-demand Distance Vector — маршрутизация по требованию в специализированных сетях на основе вектора расстояний). Об этом можно прочитать у (Perkins and Royer, 1999). AODV является дальним родственником алгоритма Беллмана—Форда (Bell­man—Ford) (метод векторов расстояний), адаптированным для работы в мобиль­ной среде и принимающим в расчет ограниченность пропускной способности и срока службы элементов питания — свойства, характерные для мобильных се­тей. Еще одной необычной характеристикой является то, что AODV — это алго­ритм «по требованию», то есть он вычисляет маршрут только в тот момент, когда появляется желающий отправить пакет тому или иному адресату. Посмотрим, что это значит,