|
|
Close Help | ||||||||||||||
|
|
|
Close Help | ||||||||||||||
5. Сетевой уровень
5.1. Проблемы построения сетевого уровня5.1.1. Сервис, предоставляемый транспортному уровню
5.1.2. Внутренняя организация сетевого уровня
5.1.3. Сравнение подсетей с виртуальными каналами и дейтаграммами
Сетевой уровень предоставляет сервис транспортному через интерфейс между ними. Этот интерфейс особенно важен так как представляет собою границу между пользователем и средой передачи, границу подсети. Часто среда передачи контролирует протоколы и интерфейсы вплоть до сетевого уровня. Ее задача доставить пакеты пользователя.
Сервис сетевого уровня разрабатывался в следующих целях:
Кроме перечисленных целей разработчик сетевого уровня свободен в разработке сервиса сетевого уровня. Однако, эта свобода выливается в жестокие баталии. Основной их причиной является вопрос: должен ли сетевой уровень быть ориентированным на соединения или нет?
Представители лагеря Internet: задача сетевого уровня передвигать биты туда сюда и ничего более. С их точки зрения подсеть не надежна по определению, вне зависимости от того как она построена. Поэтому, хосты должны заботиться о надежности, т.е. контролировать ошибки и управлять потоками.
Отсюда следует что сервис на сетевом уровне должен быть не ориентирован на соединения, с примитивами типа SEND_PACKET, RECEIVE_PACKET. Никакой проверки упорядочения пакетов, управления потоком не должно здесь быть. Это все делают хосты.. Каждый пакет должен нести полный адрес доставки, поскольку они отправляются абсолютно независимо.
Представители другого лагеря - телефонные компании, основываясь на своем 100-летнем опыте эксплуатации телефонных сетей, считают, что сетевой уровень должен быть надежным и ориентированным на соединения. С их точки зрения соединения должны обладать следующими свойствами:
Другие возможности такие как гарантированная доставка, явное подтверждение доставки, приоритетные пакеты являются не обязательными. Как мы уже отмечали в главе 1, сервис не ориентированный на соединение подобен обычной почте, а ориентированный на соединение - телефонной системе.
Спор между сторонниками сервиса с соединениями и без соединений - это, по существу, спор о том где разместить основную вычислительную сложность. Сервис ориентированный на соединение предполагает, что эта сложность приходится на сетевой уровень, т.е. на подсеть. Сервис без соединений - на транспортный уровень, а стало быть на хост. Защитники сервиса без соединения говорят, что стоимость вычислительных средств падает, а их мощность растет, так что нет причин нагрузить хост. В то же время подсеть - это как бы все общая инвестиция и часто модернизировать подсеть вряд ли будет возможно. Так что она должна оставаться неизменной как можно дольше. Кроме этого, для многих приложений скорость доставки важнее, чем ее аккуратность.
Сторонники сервиса ориентированного на соединение считают, что большинство пользователей не хотят гонять сложный транспортные протоколы на своих машинах. То что им надо, так это надежный сервис, а таковой могут предоставить соединения на сетевом уровне. Более того, многие приложения такие как передача звука и изображения в реальном масштабе времени легко можно делать по соединениям на сетевом уровне, чем над сетевым уровне без соединений.
Так каким же должен быть сетевой уровень надежным, ориентированным на соединения или не надежным без соединений? Два ответа на этот вопрос предоставляют Internet и ATM. В Internet сетевой уровень без соединений и предполагается не надежным. В АТМ - с соединениями и надежный. Естественный вопрос: как Internet работает над АТМ? Сначала на уровне АТМ устанавливается соединение между источником и получателем, а потом над этим соединением работает TCP/IP как это показано на рис. 5-1. Однако, здесь очень много избыточности и не нужного дублирования. Так, например, АТМ уровень гарантирует, что пакеты доставляются точно в том порядка, в каком они отправлялись источником, тем не менее на уровне ТСР происходит проверка последовательности пакетов и переупорядочение. (См. RFC 1577)
С точки зрения внутренней организации сетевой уровень делится на ориентированный на соединения и без соединений. В первом случае соединение называют виртуальным каналом, по аналогии с физическим каналом в телефонных сетях. Во втором случает, о пакетах говорят о как о дейтаграммах по аналогии с телеграммами.
Идея виртуального канала избежать маршрутизации для каждого пакета. Маршрут устанавливается один раз при установлении виртуального канала между отправителем и получателем и в дальнейшем не меняется до тех пор, пока передача не закончится. Подсеть запоминает выбранный маршрут. После окончания передачи, когда соединение разрывается, виртуальный канал разрушается также.
При подходе без соединения маршрутизируется независимо каждый пакет. Разные пакеты могут следовать разными маршрутами. Продвижение по разным маршрутам может требовать разное время. В следствии такой организации подсеть более надежна, способна гибко реагировать на ошибки и заторы. Позже мы вернемся к обсуждению всех pro и contra этих двух подходов.
Каждый маршрутизатор в сети ориентированной на виртуальные каналы должен помнить какие каналы проходят через него. У каждого маршрутизатора есть таблица виртуальных каналов. Каждый пакет должен иметь дополнительное поле, где храниться номер виртуального канала. Когда пакет приходит к маршрутизатору то , зная линию по которой он пришел и номер виртуального канала, указанный в пакете, по таблице маршрутизатор устанавливает, по какой линии надо отправить пакет далее.
При установлении соединения номер виртуального канала выбирается из числа не используемых в данный момент на данной машине. Так как каждая машина выбирает номер канала независимо, то этот номер имеет лишь локальное значение.
Заметим, что каждый процесс должен указать ожидаемое время освобождения виртуального канала. В противном случае возникнут проблемы с принятием решения при освобождении виртуального канала: может быть одна из машин на маршруте “зависла”?
Итак, при использовании виртуальных каналов подсети предстоит не мало работы. В случае дейтаграмм никакой таблицы виртуальных каналов не надо иметь в каждом маршрутизаторе. Вместо этого у них есть таблица, в которой указано какую линию надо использовать чтобы доставить пакет по тому или иному адресу. Такая таблица нужна и при виртуальных каналах, когда устанавливается соединение.
У каждой дейтаграммы должен быть полный адрес доставки. В больших сетях этот адрес может быть достаточно большим ( десятки байт). Когда пакет поступает маршрутизатор по таблице и адресу определяет по какой линии надо отправить эту дейтаграмму и посылает ее туда.
Результаты сравнения подсетей этих двух видов собраны на рис. 5-2.
Выбор той или иной внутренней организации подсети требует определенного компромисса. Так, например, использование виртуального канала избавляет от необходимости прописывать в каждом пакете длинный адрес доставки. Однако, в то же время это предполагает затраты памяти у маршрутизатора на хранение таблиц. Так, что здесь явный компромисс между пропускной способностью и памятью маршрутизатора.
Другим компромиссом является время установки соединения в сравнении с временем на разбор адреса доставки. В подсетях с виртуальными каналами требуется время на установление канала. Но раз установленный затраты на направление по нему пакета не требуют больших усилий. При дейтаграммном подходе надо выполнять каждый раз достаточно сложную процедуру, чтобы определить куда посылать дейтаграмму.
Виртуальные каналы имеют известные преимущества при борьбе с заторами, так как при установке виртуального канала можно заранее зарезервировать ресурсы. Начав передачу пакетов, можно быть уверенным, что необходимая пропускная способность и ресурсы маршрутизатора есть. Борьба с заторами при дейтаграммном подходе много сложнее.
Для систем обработки транзакций (кредитные карты, всякого рода покупки через сеть) накладные расходы на установление виртуального канала каждый раз были бы расточительны. Однако, постоянные виртуальные соединения, устанавливаемые вручную на недели иили месяцы, вполне оправданы.
Виртуальные каналы слабо устойчивы к сбоям. Если при работе подсети хоть на какое-то время выйдут из строя маршрутизаторы, то все виртуальные каналы проходящие через них будут разрушены. В то же время при использовании дейтаграмм самое большее что произойдет при временном отказе маршрутизатора - пропадут пакеты, находящиеся в это время в памяти маршрутизаторов и не более.
Следует подчеркнуть что качество сервиса (с соединением или без) и внутренняя организация посети - виртуальные каналы или дейтаграммы - вопросы независимые. Теоретически возможны все четыре комбинации. Возможны сервис с соединением на дейтаграммных подсетях когда надо обеспечить очень надежный сервис. Сервис бес соединения над виртуальными каналами - TCP/IP над АТМ. Примеры всех четырех случаев представлены на рис. 5-3.
Основной задачей сетевого уровня является маршрутизация пакетов. Независимо от того какую внутреннюю организацию имеет подсеть - с виртуальными каналами или дейтаграммную, пакеты маршрутизируются. Разница лишь в том, что в первом случае этот маршрут устанавливается один раз для всех пакетов, а во втором - для каждого пакета. В первом случае говорят иногда о маршрутизации сессии потому, что маршрут устанавливается на все время передачи данных пользователя, т.е. сессии (передачу файла).
Алгоритм маршрутизации - часть программного обеспечения сетевого уровня, и отвечает за определение по какой линии отправлять пакет дальше. В независимости от того выбирается ли маршрут для сессии или для каждого пакета алгоритм маршрутизации должен обладать рядом свойств: корректностью, простотой, устойчивостью, стабильностью, справедливостью и оптимальностью. Если корректность и простота комментариев не требуют, то остальные свойства надо разъяснить. Алгоритм маршрутизации должен сохранять работоспособность не зависимо ни от каких сбоев или отказов в сети, изменений в ее топологии: отключение хостов, машин подсети, разрушения каналов и т.п. Алгоритм маршрутизации должен адаптироваться ко всем таким изменения, не требуя перезагрузки сети или остановки хостов.
Стабильность также весьма важный фактор. Существуют алгоритмы маршрутизации, которые никогда не сходятся к какому-либо равновесному состоянию как бы долго они не работали. Справедливость значит, что все пакеты будут обслуживаться равномерно, ни какому направлению не будет отдаваться предпочтение, для всех абонентов будет всегда выбираться оптимальный маршрут. Надо отметить, что справедливость и оптимальность часто могут вступать в противоречие друг с другом. На рис. 5-4 приведен пример такого противоречия. Трафики между А-А”, В-В”, С-С” могут уже забить канал между Х-Х”. Поэтому вместо кратчайшего маршрута между Х и Х” надо будет выбирать какой-то другой маршрут.
Прежде чем искать компромисс между оптимальностью и справедливостью мы должны решить что является критерием оптимизации. Минимизация средней задержки пакета один из возможных критериев. Другой - максимизация пропускной способности сети. Однако, эти критерии конфликтуют. Согласно теории массового обслуживания если система с очередями функционирует близко к своему насыщению, то задержка в очереди увеличивается.. Как компромисс во многих сетях минимизируется число переходов между маршрутизаторами - один такой переход мы будем называть скачком (hop). Уменьшение число скачков сокращает маршрут, а следовательно сокращает задержку, а так же минимизирует потребляемую пропускную способность при передаче пакета.
Алгоритмы маршрутизации можно разбить на два больших класса: адаптивные и не адаптивные. Не адаптивные алгоритмы не принимают в расчет текущую загрузку сети и состояние топологии. Все возможные маршруты вычисляются заранее и загружаются в маршрутизаторы при загрузке сети. Такая маршрутизация называется статической маршрутизацией.
Адаптивные алгоритмы наоборот определяют маршрут исходя из текущей загрузки сети и топологии. Адаптивные алгоритмы различаются тем, где и как они получают информацию (локально от соседних маршрутизаторов или глобально ото всех), когда они меняют маршрут ( каждые D Т секунд, когда меняется нагрузка, когда меняется топология), какая метрика используется при оптимизации ( расстояние, число скачков, ожидаемое время передачи).Прежде чем мы приступим к рассмотрению конкретных алгоримов маршрутизации сформулируем принцип оптимальности. Этот принцип утверждает, что если маршрутизатор J находится на оптимальном пути между маршрутизаторами I и K, то оптимальный маршрут между J и K принадлежит этому оптимальному пути. Это так, поскольку если существование между J и K оптимального маршрута отличного от части маршрута между I и K противоречил бы утверждению об оптимальности маршрута между I и K.
Следствием из принципа оптимальности является утверждение что все маршруты к заданной точке сети образуют дерево с корнем в этой точке. Это дерево называется деревом погружения и его иллюстрирует рис. 5-5.
Поскольку дерево погружения - это дерево, то там нет циклов так, что каждый пакет будет доставлен за конечное число скачков. На практике все может оказаться сложнее. Маршрутизаторы могут выходить из строя и наоборот появляться новые, каналы могут выходить из строя, разные маршрутизаторы могут узнавать об этих изменениях в разное время и т.д. и т.п.
Наше изучение алгоритмов маршрутизации мы начнем со статического алгоритма широко используемого на практике в силу его простоты. Идея этого алгоритма состоит в построении графа подсети, где вершины - маршрутизаторы, а дуги - линии связи. Алгоритм находит для любой пары абонентов наикратчайший маршрут в этом графе.
Проиллюстрируем концепцию наикратчайшего пути на рис. 5-6. Расстояние можно измерять в скачках, а можно в километрах. Тогда маршрут АВС длиннее маршрута АВЕ. Возможны и другие меры. Например, дуги графа могут быть размечены величиной средней задержки для пакетов. В графе с такой разметкой наикратчайший путь - наибыстрейший путь, которые не обязательно имеет минимальное число скачков или километров.
В общем случае метки на дугах могут быть функциями от расстояния, пропускной способности, среднего трафика, стоимости передачи, средней длины очереди и других факторов. Изменяя весовую функцию алгоритм будет вычислять наикратчайший путь в смысле разных мер.
Известно несколько алгоритмов вычисления наикратчайшего пути в графе. Один из них был предложен Дейкстра. Все вершины в графе помечаются в скобках расстоянием до исходной вершины вдоль наилучшего известного пути. Изначально никаких путей не известно и все вершины помечены бесконечностью. По мере работы алгоритма и нахождения путей метки могут меняться. Все метки могут быть либо пробными либо постоянными. Изначально все метки пробные. Когда обнаруживается, что метка представляет наикратчайший возможный путь до исходной вершины, она превращается в постоянную и никогда более не меняется.
На рис. 5-6 показан процесс построения маршрута. Самым интересным является момент 5-6 (е). Здесь в окрестности вершины Н оказывается вершина F, у которой пробная метка показывает, что путь через F короче. Поэтому метка у вершины Н меняется так, как если бы маршрут шел через вершину Н. На рис. 5-7 дано описание алгоритма. Надо сделать оговорку что алгоритм строит наикратчайший путь, начиная от точки доставки, а нет от точки отправления. Поскольку граф не ориентированный, то это никакого влияния на построение пути не оказывает.
Все современные сети используют динамическую маршрутизацию, а не статическую. Один из наиболее популярных алгоритмов - маршрутизация по вектору расстояния. Этот алгоритм построен на идеях алгоритмов Беллмана-Форда и Форда-Фолкерсона. Он изначально использовался в сети ARPA и используется по сей день под названием RIP алгоритма. Он используется в сети Novell, AppleTalk, Cisco маршрутизаторах.
В основе его лежит идея, что у каждого маршрутизатора в подсети есть таблица расстояний до каждого маршрутизатора в подсети. Периодически маршрутизатор обменивается информацией со своими соседями и обновляет информацию в таблице. Каждый элемент таблицы состоит из двух полей: первое - номер линии, по которой надо отправлять пакеты, чтобы достичь нужного места, второе - величина задержки до места назначения. Эта величина задержки может быть измерена в разных единицах: скачках, миллисекундах, длине очереди на линии и т.д.
Каждые Т секунд маршрутизатор шлет своим соседям свой вектор задержек до всех маршрутизаторов в подсети. В свою очередь он получает такие же вектора от своих соседей. Кроме этого, он постоянно замеряет задержки до своих соседей. Поэтому, имея вектора расстояний от соседей и зная расстояние до соседей, маршрутизатор всегда может вычислить кратчайший маршрут.
Рассмотрим пример на рис. 5-10. На рис. 5-10 (а) показана подсеть. На рис. 5-10(в) показаны вектора, которые J маршрутизатор получил от своих соседий и его замеры задержек до соседей. Там же показана итоговая таблица маршрутизации, которую J маршрутизатор вычислит на основании этой информации.
Рассмотрим как J маршрутизатор с помощью этой таблицы вычислит маршрут до G.
Проблема бесконечного счетчика.
Алгоритм маршрутизации по вектору расстояния теоретически работает хорошо, но у него есть один недостаток: он очень медленно сходится к правильному значению. Информация о появлении хорошего маршрута в подсети распространяется более или менее быстро, а вот данные о потере, разрушении какого маршрута распространяются не столь быстро.
Рассмотрим пример на рис. 5-11. Там дана линейная подсеть. Пусть изначально маршрутизатор А не работал. Поэтому у всех маршрутизаторов в подсети для него стояла бесконечность . Пусть в какой-то момент времени А был включен. П истечении определенного времени маршрутизаторы начнут обмениваться векторами и В узнает об А. Еще через один обмен векторами об А узнает С и т.д. Таким образом, информация о новом маршруте будеи распространяться линейно шаг за шагом за каждый обмен векторами. Если самый длинный маршрут в подсети имеет длину N, то потребуется N обменов векторами пока информация о новом маршруте дойдет до самого удаленного узла в подсети.
Теперь рассмотрим обратную ситуацию на рис. 5-11(в). Здесь изначально все маршрутизаторы и линии были работоспособны. Пусть в какой-то момент времени линия между А и В разрушена. В перестает видеть А, но С говорит В: Не беспокойся у меня есть маршрут до А. При этом В не подозревает, что маршрут от С до А идет через него же. При этом марутизаторы D и Е своих таблиц не меняют. Их расстояния до А на единицу больше чем у С. Плохая весть будет распространяться медленно пока счетчики задержек не примут значения бесконечности для данной сети. Только после этого станет ясно что А не достижимо ни через С, ни через D, ни через Е. Сколько времени на это потребуется, зависит от конкретного значения бесконечности в данной подсети.
Разделение направлений (Split Horizon Hack)
Одним из решений этой проблемы является следующий прием. Алгоритм работает как было описано, но при передаче вектора по линии, по которой достижим маршрутизатор Х, расстояние до Х указывается как бесконечность. Если теперь рассмотреть как будет работать подсеть на рис. 5-11(в), то там проблем возникать не будет.
Однако, рассмотрим подсеть на рис. 5-12. Если линия между С и D будет разрушена, то С сообщит об этом А и В. Однако, А знает что у В есть маршрут до D, а В знает что такой маршрут есть и у А. И опять мы сваливаемся в проблему бесконечного счетчика.
Миллионы людей в наши дни путешествуют, находятся в командировках. Многим из них просто необходимо иметь доступ к своему постовому ящику электронной почты, своей файловой системе. Так мы приходим к проблеме мобильного узла, которую мы уже отмечали. Это относительно новая проблема, но не смотря на это она стоит довольно остро.
На рис. 5-18 показана модель WAN с мобильным узлом. На этой модели мы и будем разъяснять идеи маршрутизации мобильного узла. Всех пользователей мы можем разделить на две большие группы: стационарные - это большая группа, их компьютеры подключены к сети стационарными средствами (проводами, кабелями) и редко меняют свое место положение. Другая группа постоянно меняет свое место положение и стремиться поддерживать связь с сетью. Этих пользователей мы будем называть мобильными.
Каждый пользователь в сети предполагается имеет постоянный домашний адрес, который не меняется. Проблема маршрутизации тогда заключается в том, чтобы посылать пакеты мобильному пользователю через его домашний адрес где бы сам пользователь ни находился. Все WAN на рис. 5-18 разбивается на области. В каждой области есть агент визитеров , который знает о всех мобильных пользователях в своей области. В свою очередь в каждой области есть домашний агент, который знает о всех стационарных пользователях в своей области, которые в настоящий момент путешествуют.
Как только мобильный узел подключается к местной локальной сети, он регистрируется у агента визитеров. Эта процедура примерно выглядит так:
В идеале пользователь, покидая область, должен закрыть свою временную регистрацию. Однако, как правило, закончив сеанс связи, пользователь просто выключает свой компьютер и все. Поэтому, если по прошествии некоторого времени пользователь не объявился вновь агент визитеров считает его покинувшим область.
Рассмотрим теперь что происходит когда кто-то посылает сообщения мобильному узлу (рис. 5-19).
Пакет поступает на домашний адрес пользователя, где его перехватывает домашний агент. Домашний агент инкапсулирует этот пакет в свой пакет, который он отправляет по адресу агента визитеров той области, откуда последний раз был сеанс связи с пользователем. Одновременно с эти домашний агент посылает сообщение отправителю пакета, чтобы он все последующие пакеты мобильному узлу инкапсулировал в сообщениях, направляемых по адресу агента визитеров. Такой механизм инкапсулирования одних пакетов в других называется тунелированием и мы его подробно рассмотрим позднее.
Здесь мы обрисовали лишь общих чертах основную схему работы. Конкретных схем существует множество, различающихся разными аспектами. Прежде всего тем как распределяется работа между маршрутизаторами и хостами, какой уровень в стеке протоколов хоста отвечает за реализацию соответствующих протоколов. Во-вторых, есть схемы где маршрутизаторы запоминают информацию о местонахождения мобильных узлов и могут вмешиваться в диалог между агентом визитеров и домашним агентом, заворачивая трафик. В некоторых схемах мобильный узел получает некоторый уникальный адрес, в других это адрес агента, который отвечает за маршрутизацию всего трафика мобильных узлов. Кроме этого схемы различаются разным уровнем безопасности передаваемой информации.
Когда в подсети находится в одно и тоже время слишком много пакетов, ее производительность начинает падать. На рис. 5-22 показано явление затора. Когда число пакетов, отправляемых хостами в сеть пропорционально возможностям сети, что число посланных пакетов пропорционально числу доставленных пакетов. Однако, если пакетов становиться слишком много они начинают пропадать. При перегрузке сети может случится так, что доставка пакетов практически прекратиться.
Затор или перегрузка может случиться в силу нескольких причин. Если сразу несколько потоков, поступающих по нескольким входным линиям, устремятся на одну и ту же выходную линию. Очередь на этой линии может расти бесконечно и пакеты начнут посылаться повторно, так как они слишком долго будут находиться в очереди. Если буфер маршрутизатора переполниться, то пакеты начнут теряться. Однако, увеличение памяти вряд ли исправит положение. Пакеты долго будут находится в памяти и отправители начнут их дублировать.
Перегрузки могут случаться и из-за не достаточной скорости процессора. Если процессор будет не в состоянии справиться во время с рутинными задачами ( размещения пакета в буфере, корректировка таблиц и т.п.) то даже при наличии линий с достаточной пропускной способность очередь будет расти. Аналогичная картина может случиться при быстром процессоре, но медленной линии и наоборот. Таким образом, источник проблемы - не сбалансированность производительности компонентов системы.
Перегрузки имеют тенденцию к самостоятельному росту и ухудшению ситуации. Если у маршрутизатора не хватает памяти буфера, то он начинает сбрасывать пакеты. Отправитель, не получая пакеты, начинает их повторять снова и снова, усугубляя положения получателя.
Надо различать управление перегрузками сети и управление потоком. Перегрузка - это глобальная проблема в сети. Управление перегрузками - это такая организация потоков в подсети, что потоки соответствуют пропускной способности подсети и не превышают ее. Это глобальная проблема в сети, затрагивающая поведение всех хостов, всех маршрутизаторов.
Управление потоком возникает между парой взаимодействующих хостов. Это локальная проблема, касающаяся двух взаимодействующих хостов. Ее решение гарантирует, что быстрый отправитель сообщений не “задавит” не расторопного получателя. Здесь яркими примерами могут быть: один быстрый компьютер передает файл в 1ГБ более медленному через сеть с пропускной способностью 1 Тб/с со скоростью 1Гб/с. Ясно что здесь не будет перегрузки, хотя быстрый компьютер может создать такой поток пакетов, что он захлестнет медленный. В тоже время, если в сети с линиями на 1Мб/с и 1000 компьютеров хотя бы половина машин начнет передавать файлы со скоростью 100Кб/с другой половине, то ясно, что будет перегрузка.
Часто управление перегрузкой и управление потоком путают из-за того, что и там и там применяют одинаковые приемы: направляют источникам специальные пакеты, тормозящие нарастание потоков.
В терминологии теории управления все методы управления заторами в сетях можно разбить на две большие группы: с открытым контуром и закрытым контуром. Методы с открытым контуром предполагают, что все продумано и предусмотрено заранее и если нагрузка находится в заданных пределах, то перегрузки не происходит. Если же нагрузка начинает превышать определенные пределы, то заранее известно когда и где начнется сброс пакетов, в каких точках сети начнется перепланировка ресурсов и т.п. Главное что все эти меры будут приниматься, не обращая внимание на текущее состояние сети.
Решения, основанные на замкнутом контуре, используют обратную связь. Эти решения состоят из трех частей:
При наблюдении за системой используются разные метрики для определения перегрузки. Основными среди них являются:
Следующий шаг при использовании обратной связи передать информацию о перегрузке туда, где что-то может быть сделано, чтобы исправить положение. Например, маршрутизатор, обнаруживший перегрузку, направляет всем источникам сообщений сообщение о перегрузке. Ясно, что это увеличит нагрузку в сети и именно в тот момент, когда это менее всего подходит. Однако, такая возможность есть. Другое решение - в каждом пакете зарезервировать специальный бит перегрузки и если какой-то маршрутизатор обнаружил переполнение, то он устанавливает этот бит, тем самым сообщая другим о перегрузке.
Другое решение напоминает прем, используемый некоторыми радиостанциями, направлять несколько автомашин по дорогам, чтобы обнаруживать пробки, а затем сообщать о них по радиоканалам, предупреждая другие машины, призывая их пользоваться объездными путями. По аналогии с этим решением в сети рассылаются специальные пробные пакеты, которые проверяют нагрузку и если где-то обнаружена перегрузка, то о ней сообщается всем и происходит перенаправление пакетов так, чтобы избежать перегруженные участки.
Решения с открытым контуром делятся на две группы: воздействующие на источники и воздействующие на получателей. Решения с закрытым контуром - с явной обратной связью и не явной обратной связью. Явная обратная связь предполагает, что источнику посылается специальный пакет, который информирует его о перегрузке. Не явная обратная связь основана на том, что источник сам определяет факт перегрузки на основе своих локальных наблюдений за трафиком, например, по величине задержки на поступление уведомления о доставке пакета.
Появление перегрузки означает, что нагрузка превысила, возможно временно, ресурсы системы. Есть два выхода из положения: увеличить ресурсы и сократить нагрузку. Увеличить ресурсы чаще всего не возможно. Тогда остается только сокращение нагрузки. Для этого есть несколько способов: отказ некоторым пользователям в сервисе, ухудшение сервиса всем или некоторым пользователям, заставить пользователей планировать свои потоки определенным образом.
Рассмотрение этих факторов начнем с методов, основанных на открытом контуре. Эти методы ориентированы на минимизацию перегрузок при первых признаках их проявлений, чем на борьбу с ними когда они уже случились. На рис. 5-23 перечислены основные факторы, влияющие на перегрузки, на канальном, сетевом и транспортном уровнях.
Начнем с канального уровня. Повторная пересылка может вызвать перегрузку. Если у источника сообщений часто возникает тайм-аут и он начинает повторно передавать пакет, то тем самым он лишь усугубляет положение. Близко к этому стоит явление нарушения порядка следования пакетов при передаче. Если получатель часто сбрасывает пакеты, поступившие не в надлежащем порядка от источника, то их повторная передача будет лишь усугублять перегрузку.
Организация рассылки уведомлений так же влияет на перегрузку. Если уведомление происходит немедленно и специальными пакетами, то это увеличивает трафик и следовательно может привести к перегрузкам. Если для уведомления используются пакеты с сообщениями, то возможны тайм-ауты из-за отсутствия уведомлений во время и, как следствие, повторные пересылки пакетов, что может привести в перегрузкам. В тоже время жесткая схема управления потоком ( небольшое окно) сдерживает нарастание трафика и предотвращает появление перегрузок.
На сетевом уровне выбор схемы работы: с виртуальными соединениями или дейтаграммы, влияет на появление перегрузок, так как большинство методов борьбы с ними ориентировано на виртуальные соединения. Методы управления очередями, организация очередей: одна общая на входе или одна общая на выходе; по одной на каждую входную линию или на каждую выходную; по одной очереди на каждую входную и выходную - все это влияет на появление перегрузок. Выбор метода сброса пакетов также влияет на перегрузки.
Правильная маршрутизация равномерно использующая пути в подсети существенно влияет на перегрузки. Методы регулирующие время жизни пакета в сети так же влияют на образование перегрузок. Если пакет долго блуждает в сети прежде, чем будет принято решение о его сбросе, то это плохо так как увеличивает трафик и может привести к перегрузке. Если поторопиться, то преждевременный сброс пакета может привести к повторным передачам, что опять-таки увеличит нагрузку.
Одной из основных причин перегрузки является не регулярный, взрывообразный трафик. Если бы он был более равномерный, то перегрузок можно было бы избежать. Один из методов с открытым контуром часто используемым особенно в АТМ сетях - метод формирования трафика (shaping - т.е. придание формы).
Формирование трафика регулирует среднюю скорость трафика и предотвращает тем самым его взрывообразность. Следует обратить внимание, что протокол скользящего окна лишь регулирует объем данных, передаваемых за один раз, но не скорость передачи. Здесь же речь идет именно о скорости передачи. Когда виртуальное соединение устанавливается, то пользователь договаривается с транспортной средой передачи данных о форме трафика. Если пользователь обеспечивает договоренную форму трафика, то транспортная среда обеспечивает ему доставку трафика с определенной скоростью. Для таких приложений как передача видео и аудио данных в реальном времени это очень важно.
Алгоритм текущего ведра
Идея этого алгоритма показан на рис. 5-24 (а). Ведро может наполняться с любой скоростью, но вытекать из него вода будет со строго определенной. Если вода будет поступать слишком быстро, то ее часть будет переливаться через края и пропадать. На рис. 5-26 (в) показано применение этого алгоритма к передаче пакетов в сети.
Хосту позволено передавать в сеть по одному пакету за один тик. Это достигается либо с помощью операционной системы либо с помощью интерфейсной карты. Когда все пакеты одного размера (например, как в АТМ), то этот алгоритм работает хорошо. Однако, когда пакеты разного размера все усложняется. Тогда ограничение накладывают на объем передаваемых данных за один тик.
Реализация алгоритма достаточно проста: есть одна входная очередь и одна очередь на выходе и буфер. На рис. 5-25 (а),(в) показана работа алгоритма текущего ведра.
Алгоритм ведра с маркерами
Алгоритм текущего ведра позволяет сгладить трафик, убрать нерегулярность. Однако, в целом ряде приложений бывает полезно разрешить при наличии необходимых ресурсов ускорить на некоторое время передачу пакетов в сеть. Один из алгоритмов, позволяющих это сделать - алгоритм ведра с маркерами. В этом алгоритме кроме пакетов в ведро поступают маркеры Рис.5-26 иллюстрирует этот алгоритм. Идея его заключается в том, что вместе с пакетами в ведро поступают маркеры. Пакеты из ведра уходят в сеть только при наличии соответствующего количества маркеров. Таким образом, можно накапливать маркеры и кратковременно ускорят передачу пакетов в сеть.
Другое отличие алгоритма ведра с маркером - при переполнении хосту будет временно запрещено передавать пакеты. Здесь опять существуют разные варианты в зависимости от длины пакетов, правила работы со счетчиком маркеров и т.д.
Мы опускаем правила и способы спецификации трафика.
До сих пор мы рассматривали методы управления перегрузками, основанные на открытом контуре, т.е. эти методы стараются предотвратить появление перегрузок, чем обнаружив перегрузку принять меры к ее устранению. Мы здесь рассмотрим только один метод устранения уже возникшей перегрузки - контроль доступа. Идея очень проста - если обнаружена перегрузка все что способствует увеличению трафика запрещено. Прежде всего запрещается создание новых виртуальных соединений. Таким образом, запрещается создание новых соединений на транспортном уровне. Этот метод прост в реализации и хорошо апробирован в телефонных сетях.
Другой подход разрешает установку новых виртуальных соединений, но только при наличии не перегруженных маршрутов, т.е. таких маршрутов, которые не пересекаются с перегруженными участками даже если такой маршрут далеко не оптимален. Рис.5-28 иллюстрирует этот подход.
Третий подход уже упоминался: хост и транспортная среда договариваются перед установкой виртуального соединения о форме трафика, объеме передаваемых данных, качестве сервиса и т.п. После этого транспортная среда резервирует необходимое количество ресурсов, необходимых ей для выполнения этих соглашений. Это резервирование может происходить постоянно, а может быть сделано только при возникновении перегрузок. Плата за резервирование - недоиспользованная пропускная способность.
До сих пор мы явно или не явно предполагали что соединения возникают в рамках однородной сети. Теперь мы перейдем к рассмотрению случаев, когда соединение возникает между разными сетями.
Существование разных сетей - это явление временное или оно отражает некоторые объективные тенденции? Хотя Unix работает с TCP/IP, тем не менее существует SNA от IBM, DNA от DEC, NCP/IPX от Novel, AppleTalk и т.д.
Вычислительная техника дешевеет, следовательно решение о ее приобретении опускается на нижние уровни менеджмента.
Безусловно будут появляться новые технологии, стандарты, устройства и программное обеспечение их реализующее. Все эти новации надо будет как-то связывать с существующими сетями.
На рис. 5-33 показаны различные сценарии соединений между сетями:
Название средства, соединяющего сети между собой, зависит от того на каком уровне это происходит.
Напомним, что термин шлюз мы используем для обозначения устройства, соединяющего разные сети.
Репитор - устройство обеспечивающее усиление и очистку сигнала. На МАС уровне трансивер обеспечивает передачу в пределах 500 метров. Репитор обеспечивает передачу на 2.5 км.
Мост способен хранить и маршрутизировать пакеты на канальном уровне. Он получает канальный пакет целиком и решает по какой линии его передать дальше.
Мультипротокольные маршрутизаторы - примерно то же , что и мосты, но работают на сетевом уровне. Они получают пакеты сетевого уровня и определяют куда их передать.
На рис. 5-34 показаны разные схемы включения шлюза.
На рис. 5-35 перечислены основные различия, которые могут встречаться на сетевом уровне.
Есть общих приема соединения сетей: соединение виртуальных каналов в сетях ориентированных на соединение и соединение на уровне дейтаграмм. На рис. 5-36 показано соединение виртуальных каналов. Ност одной сети устанавливает виртуальное соединение не только внутри своей сети, но и в другой, вплоть до получателя. Внутри своей сети соединение прокладывается по правилам этой сети вплоть до мультипротокольного маршрутизатора, ближайшего к сети получателя. Затем от этого шлюза до получателя по правилам сети получателя. (Рассмотреть прохождение пакетов вдоль соединения.)
На рис. 5-36 показано решение с использованием полного шлюза. Однако, такое же решение возможно и с полу шлюзом.
На рис. 5-37 показано решение на основе соединения сетей на уровне дейтаграмм. В этом подходе единственный сервис, какой сетевой уровень предоставляет транспортному - впрыскивание дейтаграмм в подсеть и надеяться на удачу. Такое соединение возможно если подсети соединяемых сетей используют одни и те же сетевые протоколы или очень близкие. Вспомним проблемы мостов между подуровнями 802.х.
Другая проблема - адресация. Различия в адресации могут быть столь велики, что соединение станет не возможным. Например, в ТСР/IP используется 32 разрядный адрес, а в OSI - десятичный номер, подобный телефонному. Выход - распространять каждую адресацию на все машины в мире. Однако, очевидно, что это не работает.
Другой выход - создать универсальный пакет, который понимали бы разные сети то же не работает. Проблема - всех уговорить признать один формат как универсальный не возможно.
Соединение виртуальных каналов (достинства): буфера можно резервировать заранее, порядок пакетов сохраняется, проще управлять повторной передачей из-за задержки, короткие заголовки пакетов.
Соединение виртуальных каналов (недостатки): хранение таблицы соединения, сложности в изменении маршрута при перегрузках, высокая надежность маршрутизаторов вдоль соединения.
Основное достоинство дейтаграммного подхода - он может использоваться между сетями, которые не поддерживают виртуальных соединений. Категория таким сетей весьма велика.
В общем случае проблема межсетевого соединения весьма сложна. Однако, есть достаточно распространенный случай, для которого есть решение. Это соединение двух одинаковых сетей через третью. Например так как показано на рис. 5-38. Решение проблемы межсетевого соединения в этом случае - тунелирование. Рис.5-39 разъясняет прием тунелирования на примере автомобиля.
Маршрутизация на межсетевом уровне происходит примерно также как на сетевом, но с некоторыми дополнительными сложностями. Рассмотрим пример на рис. 5-40. На этом рисунке внутри каждой сети также происходит маршрутизация. Она происходит и на межсетевом уровне. Так мы приходим к двум уровням маршрутизации: внутреннему межшлюзовому протоклу и внешнему. Поскольку каждая сеть в определенном смысле автономна, то часто используют термин - автономная система.
Главная сложность, опасность отличающая внутри сетевую маршрутизацию от межсетевой - государственные границы. Здесь возникают различия в законах разных стран, различия в оплате трафиков, принятые на территориях разных стран
В каждой сети есть свой максимальный размер пакетов. Это ограничение имеет несколько причин:
Максимальный размер пакета колеблется от 48 байтов у АТМ до 65 515 байтов у IP ( у протоколов более верхних уровней он еще больше).
Очевидно, первая же проблема возникает при попытке передать большой пакет через сеть, у которой максимальный размер пакета меньше. Одно из решений проложить маршрут для таких пакетов так, чтобы избежать таких ситуаций. Однако, что делать если эта сеть - сеть где расположен получатель?
Единственное решение - разрешить шлюзу разбивать пакет на фрагменты и отправлять каждый фрагмент независимо. В этом случае возникает проблема сборки фрагментов.
Есть два подхода для этого. Первый делать фрагменты столь малыми, что любая сеть на их пути будет прозрачна для них. Это решение показано на рис. 5-41 (а). Когда большой пакет поступает, его разбивают на малые и всех их отправляют на один и тот же выходной шлюз, где они собираются в большой пакет снова.
У такой фрагментации есть трудности: как узнать что все фрагменты достигли выходного шлюза, как выбирать маршрут для фрагментов, накладные расходы на разбиение на фрагменты и сборку из фрагментов пакета.
Другой подход - разбив пакет на фрагменты трактовать каждый из них как обычный пакет. Это решение показано на рис. 5-41 (в). Сборка фрагментов происходит только в узле назначения. Однако, при таком подходе каждый хост должен уметь собирать пакеты из фрагментов.
Способность соединяться любому компьютеру, где бы он ни был с любым другим компьютером - благо для пользователя, но сущее наказание для службы безопасности любой организации. Здесь кроме угрозы потери информации есть угроза притока всякой гадости типа вирусов, червей и прочих цифровых паразитов. Надо заметить, что согласно результатам исследований 50% опасности таится из вне сети, а 50% изнутри от сотрудников.
Итак нужен механизм, который бы различал "чистые" биты от "не чистых". Один способ шифровать данные. Так поступают при передаче данных. Со способами шифрования мы познакомимся позднее. Но шифрование бессильно против вирусов, хакеров и проч. нечести. Одним из средств борьбы с ними служат барьеры (firewall).
Барьер - современная форма крепостного рва. Компания может иметь сколь угодно сложную сеть, объединяющую много ЛАН. Однако, весь трафик в сеть и из этой сети идет только через один шлюз, где происходит проверка пакета на соответствие определенным требованиям. Если пакет не удовлетворяет этим требованиям, то он не допускает в или из сети. Рис.5-43.
Барьер состоит из двух маршрутизаторов, фильтрующих пакеты и шлюза приложений. Фильтры содержат таблицы сайтов, от которых можно принимать пакеты и которым можно передавать пакеты. Шлюз приложений ориентированы на конкретные приложения. Например, шлюз для эл.почты. Этот шлюз анализирует поле данных и принимает решение сбросить пакет или нет.
Internet представляет собой объединение подсетей, которые называются автономными системами. В Internet не какой-либо регулярной, специально предусмотренной структуры подсетей. Он образован из соединения большого числа подсетей, среди которых можно выделить несколько основных backbone. На рис. 5-44 показана схема соединения таких backbone. IP протокол - это то что соединяет все эти автономные системы вместе.
Как мы уже отмечали подсеть в Internet реализует сервис без соединений и работает следующим образом. Транспортный уровень получает поток данных, делит их на дейтаграммы. Дейтаграммы могут быть от 64К до 1500байт. Они передаются через подсети в Internet и если надо делятся на более короткие. Когда все дейтаграммы достигают места назначения они собираются в исходные дейтаграммы на сетевом уровне и передаются на транспортный уровень где и восстанавливается исходный поток данных.
На рис. 5-45 показан заголовок IP пакета. Он имеет обязательную часть в 20 байт и может быть расширен до 60.
Каждая машина в Internet имеет уникальный IP адрес. Он состоит из адреса сети и адреса машины в этой сети. На рис. 5-47 показаны форматы IP адресов. Классы A позволяет адресовать до 126 сетей по 16 миллионов машин, B - 16382 сетей по 64К машин, C - 2 миллиона сетей по 256 машин, D - групповая передача. Адреса выделяет только NIC - Network Information Center. Несколько адресов, показанных рис. 5-48, имеют специальное назначение. Адрес из одних 0 используется при загрузке машины.
Все машины одной сети должны иметь одинаковый номер сети в адресе. Это приводит к целому ряду проблем. По мере роста сети приходиться менять класс адреса. Появление новых адресов приводит к проблеме модификации таблиц маршрутизации и распространению информации о новых адресах по всюду. Перенос машины из одной сети в другую с последующим изменением маршрутизации, которая происходит не сразу, и пока не произошла все сообщения пойдут по старому адресу.
Решением этих проблем является разделение сети на части, которые не видны из вне, но адресуемы изнутри. Эти части называются посети. Мы уже отмечали в главе 1, что термин подсеть в Интернет имеет особый смысл. Итак, подсеть - это часть сети, не видимая извне. Изменение адреса подсети или введение новой подсети не требует обращения в NIC или изменений какой-либо глобальной базы данных. На рис. 5-49 показано разбиение сети класса В на подсети.
Для того чтобы понять как используется адрес подсети надо проследить как маршрутизатор использует IP адрес. Есть две таблицы (сеть, 0) IP адрес и (0,машина) IP адрес. Добавляется таблица (сеть, подсеть,0) и (сеть, подсеть, машина). С помощью операции И выделяется адрес подсети с помощью маски, показанной на рис. 5-49.
Управление Internet происходит через маршрутизаторы с помощью протокола ICMP. Этот протокол выявляет и рассылает сообщения о десятках событий, некоторые из них показаны на рис. 5-50.
Хотя каждая машина в Internet имеет уникальный IP адрес, но при передаче пакета через сеть от этого мало пользы, так как канальный уровень не понимает IP адресов. Как правило машина подключена к ЛВС через сетевую карту, которая понимает только ЛВС адреса канального уровня, например, Ethernet адрес. Этот адрес имеет 48 разрядов. Сетевая карта знает только такие адреса и ничего об 32 разрядных IP.
Как отобразить 32 разрядный IP адрес на адреса канального уровня, например, Ethernet адрес? Для объяснения воспользуемся рис. 5-51.
Когда машина 1 посылает сообщение машине 2, то через DNS определяется IP адрес места назначения. Далее для отображения IP адреса на Ethernet адрес посылается в подсеть запрос у кого такой IP адрес. Машина с указанным адресом шлет ответ. Протокол, который реализует рассылку запросов и сбор ответов - ARP протокол. Практически каждая машина в Internet имеет этот протокол.
Теперь рассмотрим случай когда обращение идет в другую сеть. Здесь два решения - есть определенный маршрутизатор, который принимает все сообщения, адресованные определенной сети или группе адресов - proxy ARP. Этот маршрутизатор знает как найти адресуемую машину. Другое решение - выделенный маршрутизатор, который управляет маршрутизацией удаленного трафика. Машина определяет, что обращение идет в удаленную сеть и шлет сообщение на этот маршрутизатор.
Иногда возникает обратная проблема - известен Ethernet адрес, какой IP адрес ему соответствует. Эта проблема возникает, например, при удаленной загрузке бездисковой станции. Как эта станция определит свой и соседние IP адреса?
Он посылает запрос к RARP серверу : Мой Ethernet адрес такой то, кто знает соответствующий IP адрес? RARP сервер отлавливает такие запросы и шлет ответ.
Internet состоит из сетей, управляемых разными организациями. Каждая такая сеть использует внутри свои алгоритмы маршрутизации и управления. И называется Автономной системой. Наличие стандартов позволяет преодолеть различия во внутренней организации автономных систем и обеспечить их совместное функционирование. Алгоритмы маршрутизации, применяемые внутри АС, называются протоколами внутренних шлюзов. Алгоритмы маршрутизации, применяемые для маршрутизации между АС, называются протоколами внешних шлюзов.
Изначально в качестве протокола внутренних шлюзов использовался протокол вектора расстояния (RIP). Однако, по мере роста АС он перестал удовлетворять требованиям. Проблема бесконечного счетчика, медленная сходимость не получили удовлетворительного решения. В 1979 году он был замещен алгоритмом состояния каналов. В 1988 году инженерный комитет Internet принял решение о разработке нового алгоритма маршрутизации. Этот алгоритм, названный OSPF - Open Shortest Path First, стал стандартом в 1990 году (RFC 1247).
На основе имеющегося опыта был составлен длинный список требований. Прежде всего он должен быть опубликован в открытой литературе - отсюда open. Он не должен быть собственностью какой-либо компании. В третьих, он должен уметь работать с разными метриками: расстоянием, пропускной способностью, задержка и т.п. Он должен быть динамическим, т.е. реагировать на изменении в топологии сети автоматически и быстро.
В четвертых, он должен поддерживать разные виды сервиса. Он должен поддерживать маршрутизацию в реальном времени для одних потоков и другую для других. В IP пакете есть поле Type of service, которое не использовалось существующими протоколами.
В пятых, он должен обеспечивать балансировку нагрузки и при необходимости разделять потоки по разным каналам. Все предыдущие использовали один наилучший только.
В шестых, он должен поддерживать иерархию. К 1988 году Inter стал столь большим, что ни один маршрутизатор был уже не в состоянии хранить всю топологию. Поэтому новый протокол не должен был этого требовать.
В седьмых, должна быть усилена безопасность маршрутизаторов, как защита от студентов, развлекающихся тем, что подсовывали маршрутизаторам неверную информацию о маршрутах. Наконец, надо было позаботиться о том, чтобы позволить маршрутизаторам общаться с помощью тунелирования.
OSPF поддерживает три вида соединений и сетей:
На рис. 5-52 показаны все три вида сетей. Отметим, что хосты не играют никакой роли в OSPF. OSPF абстрагируется от конкретных сетей, маршрутизаторов и хостов. Он работает с ориентированным графом, каждая дуга в котором имеет вес, представляющий задержку, расстояниеи т.п. Последовательный канал между узлами, представлют две дуги, которые могут иметь разный вес. Сеть с множественным доступом, представляет узел, соединенный с маршрутизаторами этой сети дугами с весом 0 и часто опускаемыми на рисунках. На рис. 5-52 (в) показан такой граф.
Многие АС сами по себе большие сети. OSPF позволяет разбить их на области, где каждая область это либо сеть, либо последовательность сетей. Области не пересекаются. Есть маршрутизаторы, которые не принадлежат никакой области. Область - обобщение понятия подсети. Вне области ее топология не видна.
Каждая АС имеет остовную область, называемую областью 0. Все области АС соединяются с остовной, возможно через тунелирование. Так что можно из одной области попасть в другую через остовную. Тунель представлен в графе дугой с весом. Людой маршрутизатор, соединенный с двумя или более областями, - часть остовной области. Как и в других областях топология остовной области не видна из вне.
Внутри области у каждого маршрутизатора одинаковая база данных состояний каналов и одинаковый алгоритм наикратчайшего пути. Его задача вычислить наикратчайший ауть до другого маршрутиазтора этой области, включая маршрутизатор, соединенный с остовной областью. Маршрутизатор, соединенный с двумя облатсями дожен иметь две базы данных и выполнять два алогритма наикратчайшего пути независимо.
OSPF использует несколько графов, один с разметкой как задержка, другой - пропускной способностью, третий - надежностью. Хотя все три требуют соответствующих вычислений, но зато получаем три маршрутиа, оптимизированный по задержке, пропускной способности и надежности.
Во время функционирования возникают три вида маршрутов: внутри области, между областями и внутри АС. Внутри области - вычислить этот маршрут просто - наикратчайший до маршрутизатора внутри области. Между областями вычисляется в три этапа: от источника до остовной области, от остовной до области назначения, внутри области назначения. Рис.5-53 показывает эти три вида маршрутов.
OSPF различает четыре класса маршрутизаторов:
Эти классы могут пересекаться. Например, маршрутизатор из остновной области, но не на ее границе - внутренний.
Когда маршрутизатор загружается он рассылает сообщение Hello всем своим соседям: на линиях точка-точка, группам маршрутизаторов в ЛВС с множественным доступом, чтобы получить информацию о своем окружении.
В OSPF маршрутизаторы обмениваются данными не со своими соседями, а со смежными маршрутизаторами. Это не одно и то же. Маршрутизатор не общается со всеми маршрутизаторами, например, ЛВС, а лишь с тем, кто объявлен как выделенный маршрутизатор. У выделенного маршрутизатора есть дублер, который имеет ту же информациою, что и основной.
Периодически в ходе работы маршрутизатор рассылает всем своим смежным маршрутизаторам сообщение LINK STATE UPDATE. В ответ все смежные маршрутизаторы шлют информацию о состоянии своих линий и стоимость для базы данных топологии соединений. Каждое LINK STATE UPDATE сообщение имеет номер, которое используется в ответе.. Таким образом маршрутизатор, может определить пришедший ответ несет новую информацию, по сравнению с той, что есть в его базе, или старую.. Маршрутизаторы рассылают эти сообщение когда у них появляются новые линии, или разрушаются старые или меняется стоимость линии.
DATABASE DESCRIPTION сообщение содержащее последовательные номера описаний каналов в базе данных отправителя. Сравнивая свои значения с теми, что у отправителя, получатель может определить у кого наиболее свежая информация.
Используя сообщение LINK STATE REQUEST маршрутизатор может в любой момент запросить информацию о любой линии у другого. Наиболее свежая информация распространяется другим. Все сообщения передаются как IP пакеты. Все типы сообщений показаны в таблице 5-54.
Маршрутизаторы в остовной области делают все что было здесь описано, а так же они обмениваются информацией с пограничными маршрутизаторами, чтобы уметь вычислять наилучший маршрут от любого маршрутизатора остовной области до любого другого маршрутизатора.
Для маршрутизации между АС используется BGP - протокол пограничных шлюзов. Его основное отличие от OSPF проистекает из различия в целях. При маршрутизации внутри АС основная цель - наикратчайший маршрут. При маршрутизации между АС надо учитывать и ряд политических условий, вызванных политикой конкретной АС.
Например, какая-то АС может не допускать маршрутизацию через себя ни для какой другой АС ( у них нет другого кратчайшего пути - это их проблемы); может разрешать лишь определенным. Типичными примерами таких ограничений могут быть:
Такие правила в ручную вводятся в каждый BGP маршрутизатор. С точки зрения BGP маршрутизатора весь мир состоит из BGP маршрутизаторов. По степени интереса направления трафика через сеть, сети делятся на три категории. Первая - тупиковые сети они никуда не ведут. У них только одна точка соединения в BGP графом. Они не могут использоваться для транзита. Сети с множественными соединениями. Они могут использоваться для транзита если допускают его. Транзитные сети - такие как остовные, которые предназначены для транзита трафика, возможно с некоторыми ограничениями.
Пара BGP маршрутизаторов взаимодействуют через TCP соединение. Это обеспечивает надежность передачи информации и прячет все подробности от сетей, через которые оно проходит.
BGP - это протокол на основе вектора расстояний. Однако, вместо стоимости для каждого места в сети, он хранит конкретный маршрут. Своим соседям он передает не вектор расстояний, а те маршруты, которые он использует. На рис. 5-55 показан пример.
BGP протокол легко решает проблему бесконечного счетчика. Предположим, что маршрутизатор G или линия FG отказали. Тогда F получит от своих соседей три оставшихся маршрута до D. Поскольку маршруты IFGCD и EFGCD проходят через F, то он их отбросит и воспользуется FBCD. Определение BGP протокола дано в RFC 1654, RFC 1268.
Обычно в IP сетях один отправитель взаимодействует с одним получателем. Однако, в ряде приложений бывает полезным одно и тоже сообщение передать сразу нескольким получателям. Примеры, поддержка обновления данных в реплицируемых базах данных, передача биржевой информации сразу нескольким брокерам, поддержка телеконференций.
В IP сетях групповая адресация поддерживается с помощью адресов класса D. 28 разрядов есть для адресации группы, т.е. можно адресовать 250 миллионов групп. При передаче сообщения группе делается все возможное чтобы каждый член группы получил сообщение, но это не гарантируется.
Поддерживается два типа групповых адресов: постоянные и временные. Примеры постоянных групповых адресов:
Временные группы должны создаваться специальным образом и специальным образом удаляться. Каждый процесс на машине может запросить аппаратуру присоединиться к определенной группе или покинуть группу. Когда последний процесс на данной машине покинет данную группу, то эта группа более не представлена на этом хосте. Каждый хост следит какие группы на нем представлены.
Групповая адресация реализуется специальным групповым маршрутизатором, который может размещаться отдельно от обычного маршрутизатора. Раз в минуту каждый групповой маршрутизатор рассылает через канальный уровень запрос всем хостам ЛВС указать каким группам принадлежат их процессы. Эти запросы и ответы на них регулируются IGMP протоколом (Internet Group Management Protocol), который очень похож на ICMP. Он описан в RFC 1112.
Популярность Internet обернулась против него. Не стало хватать адресов. В 1987 году считалось 100 000 сетей очень много. Что это число не скоро будет достигнуто. Оно было превзойдено в 1996 году. Проблема в том, что адреса выделяются классами. Многие организации не используют всего диапазона адресов, выделенного им класса.
Класс В наиболее часто используемый слишком велик для многих организаций. На основе имеющегося опыта видно, что было бы не плохо если бы класс С имел не 256 машин, а 1024.
Другая проблема - взрыв таблиц маршрутизации. Маршрутизатор не должен знать о каждой машине в сети, но должен - о каждом маршрутизаторе. На сегодня пол миллиона адресов класса С было выделено, следовательно не менее полумиллиона маршрутизаторов надо помнить. Каждая строка из полу миллиона показывает как достичь ту или иную сеть.
Кроме этого многие алгоритмов маршрутизации требуют, чтобы маршрутизаторы периодически обменивались бы своими таблицами. Чем больше эти таблицы, тем больше шансов, что при передаче они будут повреждены и переданы не верно.
Выход - в увеличении иерархии адресов в Internet. Указывать страну, область, город, район, машину. Однако, 32 бита не хватит. Кроме этого, Лихтенштейн , например, будет иметь столько же адресов, сколько и США.
Так что каждое решение несет свои проблемы. В настоящее время широко распространяется решение на основе протокола CIDP протокола RFC 1519. Идея состоит в том, что на сегодня не использовано более 2 миллионов сетей класса С. Тогда выделять по запросу организации несколько последовательных сетей класса С, так чтобы покрыть требуемое число машин. Например, если организация заявлен 2000 машин, выделить ей 8 последовательных сетей класса С, что даст 2048 машин.
В соответствии с эти были изменены правила определения места для адресов класса С. Мир был поделен на четыре зоны. Каждой зоне была выделена часть адресов класса С.
Таким образом каждый регион получил 32 миллиона адресов для раздачи, а 320 миллиона адресов класса С с 204.0.0.0. по 223.255.255.255 зарезервировано на будущее. Это существенно упростило работу с таблицами маршрутизации. Любой маршрутизатор, получив адрес в диапазоне 194.0.0.0 по 195.255.255.255 знает что его надо переслать по одному из европейских маршрутизаторов.
Хотя CIDR может продлить на несколько лет существующую версию Internet IPv4, но ясно что дни ее сочтены. Круг людей, использующих Internet резко растет. Если раньше это были в основном университеты, госучереждения, то теперь это комерческие организации, моблильные пользователи и т.п. В придверии нового века и, под давлении роста Internet инженерный комитет nternet предпринял проект по создании новой версии IP. Основными целями этого проекта стали:
В 1993 году был опубликован протокол SIPP - Simple Internet Protocol Plus, который был принят как IPv6. IPv6 не совместим с IPv4, но может работать с TCP, UDP, ICMP, IGMP,OSPF,BGP DNS/ Более подробно его можно посмотреть в RFC 1883, 1887.
Первое и главное отличие IPv6 - более длинный адрес - 16 байт. Это решает одну из главных задач - неограниченное расширение Internet.
Второе - заголовок стал проще (всего 7 полей), что ускорило обработку и маршрутизацию.
Третье - он лучше поддерживает варианты в заголовке, что делает работу с ним более гибкой, позволяя опускать не нужные поля и вводить необходимые.
Четвертое - серьезно улучшена безопасность протокола. Идентификация и конфиденциальность - ключевые возможности нового IP.
Наконец, существенно улучшена работа с типом сервиса, особенно учитывая возрастающий multimedia трафик.
