Продолжение. Предыдущая Часть 2.

Управление трафиком (Traffic Engineering)

В некоторых случаях решение о направлении пакетов по маршруту A S1 S2 S4 B может иметь существенное значение, если, например, линк S2–S4 будет медленнее остальных, или больше перегружен.

Термином traffic engineering обозначают технологии выбора наилучших маршрутов по тому или иному критерию. Так же может называться приоретизация трафика одного типа над другим, например, пакетов речевого IP-соединения перед обычными пакетами с данными.

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

При обычном продвижении пакетов, или датаграмм (datagram forwarding) на уровнях LAN или IP, маршрут пакета определяется только конечной точкой маршрута этого пакета (destination) и управление трафиком ограничивается выбором между альтернативными маршрутами.

Однако, при выборе дальнейшего линка в продвижении пакета могут приниматься во внимание также соображения «качества обслуживания» QoS (Quality of Service). Например, при передаче пакетов вещательного видео-соединения по сети с относительно низкой полосой пропускания, при отсутствии требования к задержкам (что часто бывает при передаче видео), видео-трафик может быть пропущен через полностью другой маршрут, относительно пактов «общего назначения», даже если время передачи пактов по такому маршруту будет дольше. Либо, администратор сети может просто предписать видео-трафику более высокий приоритет, чтобы пакеты не ждали в узлах сети своей очереди на маршрутизацию.

Маршрутные петли (Routing Loops)

Недостаток передачи пакетов состоит в том, что при этом могут образовываться маршрутные петли. То есть, в таблицах маршрутизации могут случайно оказаться установки такие, что пакеты будет передаваться по замкнутому маршруту. Например, на предыдущем рисунке может появиться несуществующий пункт назначения С, при этом S1 будет отправлять пакеты на S2, S2 – на S4, S4 – на S3, а S3 – на S1. Если такое происходит, то есть опасность, что пакеты, отправляемые с А на С, будут бесконечно бегать по кругу, попусту перегружая узлы сети. Маршрутные петли обычно возникают, если таблицы маршрутизации централизованно рассылаются по узлам, а никто не проверяет, есть ли в них несоответствия. Если даже кто-то проверяет, то всё равно петли могут кратковременно возникать, поскольку извещения об их образования могут запаздывать.

Протоколы передачи пакетов должны иметь средства по обнаружению маршрутных петель и своевременного избавления от них путём коррекции таблиц маршрутизации в тех узлах, где такие петли возникают. Например, протокол Ethernet может отправлять пакеты, попавшие в петли, назад, на тот узел, откуда они пришли. Протокол IP выделяет в заголовке пакета один байт под параметр «Время жизни» TTL (“Time to Live”). Он устанавливается узлом-источником пакета, и число TTL уменьшается на единицу при каждой передаче на следующий узел. Когда TTL=0, пакет уничтожается.

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

Например, в фрагменте сети из пяти узлов A-B-C-D-E на рисунке ниже, узел D должен передать пакет на узел В.

Из каких-то соображений, узел D решает, что наилучший путь передачи от D на В – это D-E-C-B. После передаче пакета на узел Е, тот в свою очередь решает, что наилучший путь – это E-D-A-B. И отправляет пакет обратно на D. Тот опять выбирает маршрут D-E-C-B. Чтобы предотвратить такую игру в пинг-понг, необходима кооперация между узлами в процессе маршрутизации и глобальный взгляд на сеть со стороны системы управления.

Перегрузка узлов (Congestion)

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

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

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

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

(Продолжение здесь).